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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lighting Talk: Lessons Learned from Writing Thousands of Lines of IaC - Eran Bibi, Firefly

Description

Lighting Talk: Lessons Learned from Writing Thousands of Lines of IaC - Eran Bibi, Firefly

Immutable architecture is the backbone of infrastructure as code & cloud native operations, to ensure production environments cannot be changed during runtime. While this has the benefits of its inherent safety measures, this can also be restrictive, all while creating new challenges for security. Immutable concepts are much more effective when it comes to securing cloud native environments and infrastructure, which is becoming an increasingly more complex task. This talk will focus on some of the fundamentals of immutable architecture, best practices and recommended design patterns to work around its limitations and enhance security, as well as what you most certainly should not be doing when running immutable architecture both from an infrastructure and security perspective. This will be demonstrated through a real-world example of deploying a single-tenant SaaS in an automated pipeline, typical challenges encountered, and what was learned on the way, through a Terraform, Kubernetes and step functions example.

A

Welcome, thank you for being here. My name is iran bibi and I'm the co-founder of firefly. Before that I was the head of devops at aqua security, and I have a lot of experience with writing infrastructure as code, I think from the last seven years, and I have few lessons learned that I would like to share with you. I only have 10 minutes, so I pinpoint those only to three lessons focusing on security.

A

So the first part will be talking about state file. State file in a nutshell, for anyone that doesn't familiar is one of the component that involved infrastructure as code, so the stat file being used in order to the compiler, for example, the terraform or the pulumi, to map the infrastructure into the actual state of the cloud.

A

One of the pitfalls.

A

On provisioning cloud resources, but you need to be alerted that if this state file be exposed or a third party have a scanning capability on the place that you are put in your state file, for example, an s3 bucket or some data store, that third party might be having your either access key to deploy stuff on your aws environment or your database credential and in other cases after certificate.

A

So a state file is something very sensitive. It's a clear text file uh format in a json, but you need to make sure nobody even access, or at least have the the option to read that file beside the infrastructure as code compiler.

A

The second lesson is about infrastructure drift, so drift is a state when the actual configuration on the cloud diverged from the stuff that you planned to be that's sitting on your source control, and this is something surprisingly very common. You are deploying infrastructure. Everything is aligned.

A

Your code is basically reflect the stuff that you have on the cloud, but over time, because a lot of people have access to the cloud or a third-party application have a permission to alter the cloud you may find those differences and, in some of the cases, drift can be a security vulnerability.

A

Let me show you an example. In the left side, we have a terrible manifest declaring an dns record, a role for dns record with a permission to list the dns. However, over time when I access the cloud console- and I see what the actual configuration is, I can notice there is a slight change. It's only one line that said route, 53 asterisks, basically giving a full access to the specific role, so any service, any machine that have assigned uh to that specific role.

A

If you look on the git, you think it's a read-only access, but on the real-life scenario, it's basically a full permission.

A

The third lesson is about models, so models is a very easy way to use infrastructure as code. Instead of writing repeatedly the same lines over and over, you can basically grab something that is out there online on some registry on some public git repository and utilize it for your project.

A

So the advantages of using models is is, is huge, it's easy to use. It's outer. You can save a lot of development time because somebody else already written it, but it can be so it can be a malicious in some cases and also might include misconfiguration.

A

This is an example of a tearful module that exists on terraform registry that basically giving cross-account access to the attacker, so the developer, without the right tooling, in place that doesn't have the context that, with those few iem roles, that this specific module is creating, is also creating additional iam role that giving cross account to an attacker account. So it's very easy to make mistakes when taking something from online.

A

If you are using module, you see only the line that having the import of the module, you don't see the content and you don't have the visibility, or at least the typical developer that doesn't have the right, tooling, doesn't have the visibility to know that even if you're doing a small test and deploy it on a sandbox account, somebody else can take over this account and use it for malicious activity to wrap everything up.

A

Few takeaways for state file make sure you are putting it in a safe place and have encryption in place that, even if someone have an access is not able to read the file, also just verify. If you already have a third party application that scanning your cloud already have access to those state file, and you should know that it's most probably that they have your aws access, keys and other uh type of sensitive data for infrastructure drift.

A

You have two options: either monitor for drift, implement some drift detection tooling or to use something that will reconcile automatically the state of your git into the the cloud. This is a methodology more in the githubs way and for the public model, just use one of your one of those security scanning tools even for models and make sure nobody will have the option in your organization to utilize unauthorized module directly from uh the web.

A

That's it hope you enjoyed the talk you can find me later on uh outside and tomorrow, in firefly booth. Take care.

B

Yeah thanks iran. This was really informative. I think we have time for maybe a question if anyone has any questions for iran- or maybe I have one question right, so you talk about this, uh these takeaways right. So do you see any automations any tools that are already available to do? Do that? Like I see there are a lot of things scanning we can do on the static file.

A

Yeah, so yes, there is a few popular open source tooling for scanning infrastructures code. You have a tfsec of aqua security, you have checkoff of bridge crew and you also have tool that we wrote in firefly called validiac.com and basically an online validator for your configuration and it's very easy to implement using the ci.

A

um I think you also need to make sure everybody is aware about this uh specific scenario of using module, because sometimes uh a developer, utilizing and not scanning, because it's not going through the cicd, but you need only one time that have some malicious configuration in your cloud in order to have the attacker option to access your aws. So it's very easy to buy bypass those scanning tools.

B

Yeah thanks iran yeah bye-bye.