As more organizations adopt Kubernetes for their infrastructure, they often turn to infrastructure as code (IaC) and GitOps as a way to manage their Kubernetes environment. While these processes can improve efficiency and reduce the risk of human error, they are not a silver bullet for Kubernetes security. In this blog, we explore the limitations of IaC and GitOps in securing Kubernetes, particularly in the context of RBAC policies. We also discuss the importance of implementing additional security controls to ensure the safety of your Kubernetes environment.
What about IaC?
Using infrastructure as code (IaC) is often touted as a way to improve security in the cloud. The idea is that by defining infrastructure in code, you can automate security controls and reduce the risk of human error. For a primer on the difference between IaC and Gitops, check out this article.
Git in Kubernetes
In the world of Kubernetes (K8s), GitOps is becoming an increasingly popular way to manage infrastructure. GitOps is a process that enables developers and operators to manage infrastructure and applications as code. With GitOps, infrastructure is defined in code and versioned in Git, allowing for automated testing and deployment of infrastructure changes. Kubernetes users rely on a declarative approach, which creates a need for a centralized location to store declarative configurations. Git repositories are a natural option for storing these specifications, making GitOps a logical delivery tool for Kubernetes.
IaC and GitOps will not suffice for Kubernetes Security
Writing good infrastructure code is hard. Just because you use infrastructure as code doesn't mean that your code is secure. There is always a risk of human error and bugs when dealing with code. IaC files are no exception. When you combine multiple IaC files in a GitOps flow, it becomes challenging to know the outcome of all the configurations. It's hard to determine whether the final state of your cluster is secure.
Similarly, while GitOps offers benefits in managing infrastructure and applications, it cannot solve the reality of Kubernetes deployments, nor security for those deployments. In many cases, teams modify clusters with ad-hoc edits outside of the CI/CD system, which increases the risk of configuration drift. Configuration drift occurs when changes to a cluster are made outside of the CI/CD system, making it harder to keep track of changes to each machine.
Over time, configuration drift can create inconsistencies in your K8s environment, leading to potential security vulnerabilities. When you rely on GitOps to manage your infrastructure, you may assume that every change made to your K8s cluster is tracked in your Git repository. But if team members are making ad-hoc changes outside of the CI/CD system, these changes won't be captured in the Git repository.
Another issue with GitOps is that it can create a false sense of security. The fact that you are using GitOps does not mean that your infrastructure is secure. It's essential to understand that GitOps is just a process for managing infrastructure as code. It's not a security tool.
Finally, GitOps doesn't help to prevent security breaches. It can help you detect issues and automate fixes, but it won't prevent an attack from happening. It's crucial to have other security controls in place, such as network security and identity and access management.
An RBAC example
To take a concrete example, RBAC is a critical element of security in Kubernetes. policies are written in YAML and determine who can access what within Kubernetes, using a specific hierarchy of roles, service accounts and more.
Perhaps you can use GitOps processes to write, store and deploy your policies. But will GitOps tell you if your roles are over-permissioned (RBAC policies can be very complicated to write)? Nope. Will it answer the question, ‘Which resources does Susie have access to in this cluster?’ Nope. Without a dedicated RBAC security tool for Kubernetes, from a security perspective, RBAC is still the same black-box it was, regardless of where the policies are created or stored with GitOps.
Conclusion
In conclusion, GitOps is an excellent process for managing infrastructure in K8s. Git repositories are a natural option for storing declarative configurations, making GitOps a logical delivery tool for deploying manifests from Git. However, GitOps cannot solve the reality of Kubernetes deployments, nor security for those deployments. IaC and GitOps are just codified configurations that are prone to human error and bugs. It's crucial to understand the limitations of GitOps and implement other security controls to secure your K8s cluster. By doing so, you can ensure that your K8s environment is both manageable and secure.
