Cloud Native Computing Foundation Cloud Native SecurityCon EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Knowing Your Serverless Functions: Signing and Verifying Serverless... Ariel Shuper

Description

Lightning Talk: Knowing Your Serverless Functions: Signing and Verifying Serverless Functions with Cosign - Ariel Shuper, Cisco

the security of software supply chains is extremely important. Malicious attacks on the software supply chain are an ever-present threat that can cause extreme damage. An increasing popular method to secure software supply chain is by creating a cryptographic evidence that the author of the code is who they say they are; based on them having access to the trusted private key and the content has not been changed since. Kubernetes provides a great infrastructure to complement code "signing" with a validation step that ensures signing prerequisites where met and only "signed" images are deployed. An admission controller can use ValidationWebHook and MutatingWebHook to verify deployments of "signed" images only. But what about Serverless functions? how can users validate their code was changed/ tempered before or after it was uploaded to their cloud account? In the absence of the admission controller equivalent how users can stay protected? In this talk we'll demostrate how to use and operate code-signing for serverless function using Cosign project and how to validate that only signed functions are being used in the cloud account (leveraging available tools).

A

Hello and I would like to talk about signing and validating serverless functions, so I prepared like a kind of an introduction, a few slides just talk about uh code signing why it's important, uh but I think after all these talks today we can skip this very basic introduction, but I think you know one key takeaway I would take from this slide. Is that there's increasing attack and increasing no interest in attacking ci cd pipelines couldn't be modified, can be changed. You heard a lot about it. We can move ahead.

A

uh Openssf was founded to address those supply chain threats, project six store started independently. Now it's part of ssf openness have to address the code pipeline phase and I'm sure there'll be a few more talks even later today about it and sig stories, of course, looking how to sign and leverage this information in ci cd pipeline.

A

How does six to work? And again it's very very just on a nutshell, so it can all be. You know on the same uh line and just like as a small background. So six story is a collection of tools uh created a very nice uh model of you know, keyless signing model. It also has the classical uh you know pub. uh The classical signing was private and public key, but if, using you know the killer signing, uh you can use full co which give you a root certificate authority.

A

Together with open id connect, uh you could get a timestamp certificate, then cosign uh can use this for signing, creating a signature record, a transparency log which should be constantly. You know, query and monitor uh to get verification and provenance, um and, as I said you know, cosine can also be used in traditional key pair in case that your ci cd doesn't support the keyless signing model and you want to use in traditional way. Okay, that's just the introduction.

A

We can move to the real topic of my of my talk now serverless. Why serverless are different. What makes them you know different than everything we heard until now that you know everybody talk about. You know how to identify. You know the hashes, what we use so container images typically identify with their hash. It's very easy. uh Today, it's a very common practice in kubernetes to validate those images before deployment, so it's almost like you know, build in whether using an open source tool like gatekeeper or kiverno, whether using your own proprietary thing.

A

This is a classical you know, security precautions being used by almost everyone to validate the images you know or were not changed or tampered now in serverless functions. Usually you upload your source code into your cloud account. So there is no hashes.

A

Now my friend here on the on the right side talked about drifts in your you know cloud you know deployments and it apply also for serverless. You know you deploy with one permission. Eventually you get some drift to get some changes, so you probably don't want just to sign. You know your code. You also want to sign the deployment file, whether using you know a cloud formation template with using any other infrastructure of the code. You want maybe also to sign it, to verify that even those uh artifacts were not were not uh changed.

A

So this is something which is probably a preliminary need now in serverless. There is one more challenge, because the cloud providers don't give you this admission controller. Those give you this, like validation function, that can validate any action before you start executing the code. So those are the challenges why serverless is like a slightly different use case than any container image or the classical.

A

uh You know signing and verification process that we do now. There is one exception in aws, so aws has its own built-in solution. It's called code signing it's a great uh step to secure serverless functions. uh You can use code signing from the functions. um You can sign your code, okay and then upload the signed code into the cloud account or to a three bucket.

A

Then you need to create a signing profile which, using you know the iem permissions to identify who and what can be signed. And then you can apply this signing profile to any lambda function that you want and it verifies that the lambda is signed and then before it execute it verify that it's signed and it's and it's secure. So this is a great approach.

A

uh What I would like to present is a an alternative approach which using sigstor to sign it, so you can use six store and cosign to sign serverless functions in their deployment file. It's a standard tool, so it can be used for any. You know cloud provider not just aws, it's designed to be used in ci cd, so it's very easy to implement and edit as part of your cd. So it's really simple: uh you have the keyless signing option, which is slightly safer.

A

It's very nice to implement it's slightly still challenging to deploy, but um it's a very nice and safer option and of course you can extend it not just to sign the function code. You can also sign. You know the same deployment file, but six are still at the moment, like appropriate validation option. It has a validation, admission controller for kubernetes.

A

It lacks a validation option for serverless functions.

A

So what we did- and this is uh in cisco- in in the emerging and technology technology, innovation team, we created an open source validation function and we created the whole template for this validation mechanism. So how? How does it work so again? Use cosine bulb option to sign your code or assign any you know, artifact that you want in your ci cd.

A

You can use the key pair, private and public or the key list, which in turn requires to deploy record uh in your environment or at least have access to it, um store the certificate and the signature in a secret storage. uh In this template we use it for km. We use the we use the in aws, so use kms for it, and then you need to create like a small mechanism for alert and eventing. So you need to get notification for any function, creation or modification.

A

So in this case, what we did we used the cloudtrail with the eventbridge, so we created a rule that only trigger create an event, a trigger function only when there is a new cloud function or modification to uh to a lambda function. Now this rule allow us to invoke a validating function. So what we wrote is a validating function. This violating function take uh the the key whether the key or the certificate take it from the kms calculate uh for this.

A

For the function which you deploy, the function which you updated, calculate the hash and calculate you know if, if the same key matches, and then it provides an output which can be used to whether you want to allow or to block uh the function invocation process. So it's you know it's like. We created, like sort of an admission controller that can be used for aws account using the native tools like cloudtrail and eventbranch.

A

You can use the same thing uh for in in azure and or in google cloud.

A

So what I would just say that you know supply chain. The risk is increasing. Serverless are special use cases, it's much harder to validate them. You can use open source tool like sigstor, which for code staining you can use open clarity. uh It's an open source. You know repository. We can find templates, you can find violating function going to be uploaded in the next few days uh and we encourage everyone to go ahead and use it. uh Give us good feedback, uh we'll be happy to fix and modify.

A

It could be for we're gonna plan to upload vitamin function for any uh cloud provider. Thank you very much.

B

Yeah thanks ariel. This was really good. So uh I have one question. So does it have any performance impact because typically people see with serverless they you need to execute very fast.

A

Right, if you are.

B

Adding these additional.

A

Steps exactly so: yes, it has a performance impact. This is why we in the validator function. We use the keeper, the public private keeper, so it's likely traditional mode, but then you can really deploy it locally and kind of a minimal performance impact.

B

Okay, interesting any other questions.

B

Okay, let's thank.

A

B

C

um Hello, do you manage the some custom uh root certificate uh for the key management of the six store to create the certificate to sign your your lambda function or you're, using just the default one cosine.

A

So I'm not sure I heard the question. Can you just repeat so you you, you sign.

C

Okay, you you sign the the damn. The function would be a six door sign or whatever, yes, but which kind of certificate you use the default one or a custom certificate from a root certificate. Okay,.

A

So you can use both right. You can use their own if it's a killer signing or you can use your own. If it's you know, you want to make it simpler to deployment. So at the moment the keyless is only working with certain frameworks, like you know, github action, so we use you know the classical traditional mode. If you want to get universal, but both options are available.

B

Yeah thanks ariel. Thank you very much.