Enforce Least Privilege & Separation of Duties during Continuous Deployment

Role-based access controls (RBAC) are an essential part of any secure Continuous Deployment Platform. RBAC enables enforcement of the principle of least privilege by limiting access to applications and services to the minimum set of users. RBAC enforces separation of duties through role-based manual approvals. This helps to meet these common requirements and provides an additional layer of security within your DevOps organization.

This blog post discusses how Armory Continuous Deployment-as-a-Service uses automation and role-based access controls to ensure that changes to production applications are properly reviewed before being released. It also describes how to restrict application access by role. Finally, we’ll provide an overview of the Armory platform’s capabilities, including tenant and role management, configuration as code, and role-based approvals.

What Are Role-Based Access Controls?

RBAC is a security system that allows administrators to limit access based on the roles of users. This ensures that only authorized users can access or modify sensitive data and systems, and can require certain users to perform certain tasks in order to ensure separation of duties.

RBAC uses roles to define permissions. Each role has its own set of permissions and restrictions. For example, a user with the “administrator” role might be able to access all applications and services, while a user with the “WebUI developer” role might only be able to access the deployment of the Web UI service.

Separation of Duties

Many companies have SOC controls that ensure their applications are stable and secure. SOC often requires a separation of duties: Code requires approval before production deployment. This often takes the form of manual role-based sign-offs. For example, someone from QA may need to sign-off that tests passed, and someone from InfoSec may need to sign off that security scanners passed. Until you implement full automation, role-based approvals allow you to enforce and audit separation of duties around these tasks within your deployment pipeline.

Historically these process typically starts with a developer creating a change request. An authorized user must review this request. If approved a release manager deploys the change to production.

Using Role-Based Approvals to Enforce Separation of Duties

Using CD-as-a-Service developers can now start the release automation process. When the code is ready for approval the required approver can be notified, and simply click a button. After approval the change deploys automatically. This prevents unauthorized changes. It also provides visibility into manual processes so that they can be automated.

To enable separation of duties Armory Continuous Deployment-as-a-Service allows any Manual approval to optionally specify a list of roles. Only a user with one of these roles is able to issue the approval. Other users can see that an approval is needed, and can see the list of roles authorized to issue it. This example shows an environment, Security-Scanning, that requires an approval by the InfoSec role before it will proceed to any downstream environments.

  Security-Scanning:
    account: demo-staging-cluster
    strategy: rolling
    constraints:
      afterDeployment:
      - pause:
            untilApproved: true
            requiresRoles:
            - InfoSec

Moving Beyond Role-based Approvals

While role-based approvals are a great way to start on your CD journey, many companies remove manual approvals from their deployment pipeline long-term. Once automation of a manual check is available it can replace the manual approvals. The role that approved the change can instead approve changes to the automation to continue enforcing separation of duties. Audits should check the approval of automation changes. Audits should also check that all changes were approved by the automation.

Enforcing Principle of Least Privilege Through Tenants

Armory CD-as-a-Service can break it’s configuration up into multiple secure tenants. This allows particular applications or teams to have their own dedicated security zone within Armory CD-as-a-Service. A tenant contains a set of Kubernetes clusters, applications, secrets, etc. Roles grant a particular access level within the scope of a tenant. Grant one or more roles to each user to give them access to their team’s resources. This allows you to easily break your application access up by team, while still supporting users who need access to applications owned by multiple teams.

The principal of least privilege requires that teams have access to the minimum permissions needed to do their job. Enforce least privilege by creating a tenant per team and giving each tenant only the resources needed for that team’s applications.

Maintaining your RBAC as Code

Modern source control systems allow advanced permissions, automated validation and change control. They are also familiar tools for the typical team setting up a CD tool. Because of this Armory CD-as-a-Service took an ‘as-code’ approach to implementing it’s RBAC rules. CD-as-a-Service defines the RBAC configuration as yaml. You can update this yaml through git, just like any other code. When changes occur, your CI system can invoke the Armory CLI to automatically apply the updated RBAC configuration. This provides full audibility and change control to ensure your security configuration is itself secure.

This example RBAC configuration for Armory CD-as-a-Service creates a tenant-restricted ‘admin’ and ‘non-admin’ role for each of two teams.

tenants:
- Team1
- Team2
roles:
    - name:Team1 Member
      tenant: Team1
      grants:
        - type: api
          resource: deployment
          permission: full
    - name:Team1 Admin
      tenant: Team1
      grants:
        - type: api
          resource: tenant
          permission: full
    - name: Team2 Member
      tenant: Team2
      grants:
        - type: api
          resource: deployment
          permission: full
    - name: Vanguard Admin
      tenant: Team2
      grants:
        - type: api
          resource: tenant
          permission: full

Conclusion

Role-based access controls are an essential part of any secure IT infrastructure. By limiting access to certain tenants, companies prevent users from modifying other team’s applications. Platform teams and developers can also leverage role-based approvals to ensure separation of duties within their application.

The Armory platform provides an automated and secure way to manage role-based access controls. It includes features such as tenant and role management, configuration as code, and role-based approvals. These features prevent users from making unauthorized changes. Do you want a secure and flexible CD solution for Kubernetes that can leverage RBAC to ensure the principle of least privilege and separation of duties? Sign up to try Armory CD-as-a-Service for free today.