Introduction to PaC
While cloud platforms and cloud native environments grow in popularity and complexity, the security challenges around it grow in an even faster way. Managing tens, hundreds and even thousands of kubernetes clusters in an organization presents a challenge: how to keep everything in line with standards and compliant with regulatory requirements?
This problem is even bigger when we start talking about cloud providers. Companies have been adopting multi-cloud strategies to guarantee the best experience to their customers and to get lower prices for the same service but from a security point of view this has increased the difficulty of keeping their environments safe, since there’s multiple tools being used and a massive surface area to cover.
With this in mind (and with the popularization of Infrastructure as Code tools) we have PaC (Policy as Code), a (not so) new concept that has changed the way we do Cloud (not only security).
Policy as code in general
The main idea around PaC is to handle configuration and standardization in your environments in an easier and more governed way. While DevOps practices are still growing around companies, standardization can benefit from these practices and Policy as Code allows you to define a portfolio of standards, all of which are allowed or even able to be customized for the environment.
By integrating PaC with DevOps practices you’re able to scale your company’s requirements and move them from manual to automated processes. Things like security and environment manageability become continuously improving while adopting software engineering best practices like source code versioning and rollback capabilities. This will allow you and your company to evaluate every change that has been made and the impacts it has shown.
While we’re talking about DevOps, PaC can also be integrated in CI/CD pipelines to ensure quality and act as a gatekeeper to the artifacts that are being deployed. This will be of great use when your environment has scaled so much that it’s hard keeping track of what is being deployed to them.
PaC was created to enable the enforcement of controls in a declarative and developer-oriented way.
In the technology world, policies can be of different kinds, like:
- YAML and JSON: Common in infrastructure resources and cloud platforms. They allow us to implement guardrails and desired configurations on platforms and services.
- Domain Security Language (DSL): A specialized language for Policy as Code or various scenarios, but less flexible than using a general purpose programming language (like Rego).
- Programming Language: More customizable than DSLs, it allows engineers to build logic inside their code, making it possible to implement complex decision structures (like Go and Python).
The syntax of a policy-based project might change, but the concept won’t!
Some scenarios of where it might be applied include:
- Authorization: A common and recommended way of implementing requests validation is through policies. Engineers are able to code a policy in a way it implements a business logic that needs to be verified before allowing any consumption from the client. Systems might as well use policies to decide whether an user has sufficient privilege to access an administration page or it doesn’t, while it interacts with the GUI to show the user the results of the authorization process.
- Validation: Policies are well-known for their use inside CI/CD pipelines. We can use custom-build policies to verify every manifest that’s being deployed in our cluster. This will help us not only to check for errors in our manifests but also to guarantee the existence of specific data in the file (like annotations, labels, and other metadata).
- Guardrails: In cloud environments it’s important to allow your engineers to use the provider’s resources but always in a secure and governed way. We can use policies to create those guardrails, making it scalable organization-wide. Those policies can help engineers to identify and remediate resources that are not following the implemented standards.
Those are just some scenarios where PaC can be used. Decision making gets way easier when it’s possible to create logic in an understandable way.
Policy for security purposes
While we mentioned the overall usage of policies in cloud native environments, they are a very powerful tool for security engineers. Policies will enable the security teams to implement security guardrails and be compliant with field-related standards.
Let’s explore a scenario where policies will make an organization compliance with a set of standards:
“Financial institutions and any organizations that store, process, or transmit payment card data must comply with the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is not a regulation but an industry standard developed by the PCI Security Standards Council, which was founded by major payment brands including Visa, Mastercard, American Express, Discover, and JCB. Compliance with PCI DSS is a contractual requirement imposed by these payment brands and their acquiring banks, and it establishes a comprehensive set of security requirements aimed at protecting cardholder data.”
In that case, if one of the requirements is that all network traffic is encrypted (in-transit), we’re able to require all resources to have in-transit encryption enabled. Or, if we need special characters and a minimum length in our passwords, a policy can be created to validate new account registrations and password changes from your users. Those controls can be implemented in a way your engineers won’t need to get into the specifics, because those controls can be applied in a centralized way.
Another way policies can help you protect your environment is through resource analysis. It’s possible to implement a control that “blocks” engineers from using a specific type of resource, like an unmanaged virtual machine image. This will help enforce the usage of corporate-specific solutions, that are already hardened and have all security controls in-place.
Public object storage services are a big problem today. Engineers might lose track of what’s stored in those buckets and accidentally allow public access to sensitive information. This can be resolved by using a policy to evaluate and enforce the encryption on those buckets, guaranteeing no sensitive data is going to be forgotten in a public storage, and ensuring appropriate access restrictions based on the data sensitivity.
Those are just some examples of basic controls that can be implemented in cloud providers. We’ll explore more cloud native options in our next post in this series, but with policy solutions like Cloud Custodian, we’re able to help ensure those controls are in place in our environment, protecting our resources and our company!
Getting started with Policy As Code
To introduce you to the next post of this series, we’re going to briefly talk about OPA (Open Policy Agent) and how it can be used in your environment for decision making.
OPA is a Policy as Code solution that uses Rego as its programming language. With Rego we’re able to create policies in a logical way, allowing engineers to translate their necessities into a structured policy and making it easy to understand all the logic inside the policy.
Below you can see an example of a policy written in Rego. This policy evaluates the source of the image a Kubernetes Deployment is trying to use. This type of verification is important to make sure your developers are only using company-compliant images that have already been scanned and cleared of vulnerabilities.
This policy can be enforced in a CI/CD pipeline that will block the execution of the deployment once it finds an image name that does not start with “hooli.com/”. That way we can drive security to our environments in a distributed way as well as provide our developers quick feedback on why their deployments are being refused.
If you want to check the effectiveness of this policy, go to https://play.openpolicyagent.org/ and play with it. This is a free environment provided by Styra (founded by the creators of OPA) that will allow you to test policies that have already been created as well as new policies, without the need to run the OPA Agent in your environment.
In our next post we’re going to talk about Cloud Native Policy as Code solutions as well as its applicability in Cloud Native environments.
We’ll see you soon!