The importance of least privilege access in your CI/CD pipeline

There are many aspects to securing a software supply chain, and these keep changing and growing as technology advances. One security practice that has stood the test of time is the principle of least privilege. It was used in software systems decades ago, and continues to stay relevant in a world where the cloud and containers have brought about immense change at every layer of the software stack. 

What is Least Privilege?

The principle of least privilege in software development is when a user is allowed to view, access, or use only the resources that are absolutely necessary to perform a task at hand. It is a foundational concept for security of software systems and is relevant in CI/CD pipelines that are used to build and deliver software today.

The principle of least privilege is a security measure that prevents developers from inadvertently introducing code that could either have a negative impact or can be turned into a black box that exposes the internals of the system to the outside world.

One way to make sure that users access only the resources they need to perform their tasks is by using groups and roles. Individual users and teams can gain access to the resources they need in a safe way that is deemed appropriate by the Admin or Ops team. Another word for this is RBAC – Role-based Access Control.

RBAC assigns each user and role a set of permissions. RBAC allows you to define who can do what in a system so that a privileged user can’t take advantage of a bug or another user to access confidential information.  

Access Controls in CI/CD

The level of privileges defined in a CI/CD pipeline enables users to access and change resources in the software system. The Admin gets visibility into the usage of these privileges in the form of logs. As users access and make changes to files and code, it is captured in logs that represent an audit trail. This, however, is reactive, after any changes are made, and while it is helpful, what’s even more important is having a proactive stance towards access controls in CI/CD pipelines.

For certain high priority assets like databases with user information, or a server running in production, access is restricted only to a very select few users who are privileged users. Even for these users, it is important to not give them anytime access, but only time-based access to just the resources they need for a specific task. This is the principle of least privilege in action in a CI/CD pipeline. Giving users unfettered privileged access because of their job title or job function is a recipe for disaster. Even if not immediate, they can become prime targets for attackers who are looking for a way to escalate privileges.

There are a couple of ways to assign privileges in a CI/CD pipeline. You can allow only certain activities to be performed by a user which they need for their task, and disallow all other activities. Another approach is to allow them access to a subset of the resources – just enough to allow them to perform their activities. In practice, both these approaches will be combined for a more mature implementation of RBAC. 

Kubernetes and RBAC

With most modern cloud-native systems being powered by Kubernetes, it is imperative for organizations to grasp how this works. RBAC in Kubernetes is different and more complex than with traditional systems. Kubernetes allows you to assign permissions to users or identities (who), to access resources in a single namespace or an entire cluster (where), so they can perform specific actions (what), and these permissions can be assigned directly or indirectly (how). With this many combinations, it is easy to get overwhelmed with enforcing the principle of least privilege in Kubernetes. 

There are two concepts to understand when it comes to RBAC in Kubernetes – Role Bindings, and ClusterRoleBindings. RoleBinding grants privileges or permissions for a user, group, or identity at the namespace level. ClusterRoleBindings are very similar, except that they assign roles to users at the entire Kubernetes cluster level. ClusterRoleBindings allow Admins to configure multiple individual pods as one namespace and enforce rules on all of them. While this makes operations easier, it should be done cautiously as the wider the permissions, the greater the attack surface. 

A practical approach to least privilege

Enforcing the principle of least privilege in development environments’ CI/CD pipelines, cloud platforms, or in a Kubernetes cluster is all about balancing operational ease with security. No doubt, security is the more important of the two. However, in the constant push for being more innovative and faster, organizations compromise on security for the sake of moving faster. They assign wider privileges to many users to simplify processes. While temporarily, this is easy, organizations pay a steep price when the system is inevitably under attack and resources are left open for attackers to view, access, change, and steal.

The best way to enforce the principle of least privilege is to use policies that can adapt to how users and workflows change. These policies should be defined in a modern security tool like Argon where they can be frequently updated, and automated. Further, the policies should be bolstered with automatic notifications and alerts whenever a user attempts to escalate their privilege, or performs an action that is not normal for their level of access. 

In summary, each component of your software supply chain is composed of smaller parts that are connected to each other. This means any small problem in one part of your application may affect the entire chain. Enforcing the principle of least privilege means to ensure that each component is secured and that users or identities cannot access sensitive data of the application from any of the smaller parts. Security principles are just as relevant today as they were in the past. However, today’s principles are more complex than those of the past. Thankfully, there are capable solutions like Argon that protect your CI/CD pipelines by making it easy to implement least privilege access and keep track of any violations.