Enterprise environments often consist of multiple teams working on different cloud native projects and applications. Each such team will work on its own assets, such as container images or functions, and use separate CI pipelines. Yet, in the end, they will often run on the same cloud infrastructure. When it comes to managing security for such environments, this complex weave of permissions and roles can get ugly quickly as more teams and stakeholders get involved. How do we ensure least privilege access is maintained without making its management unwieldy? We recently completely redesigned our RBAC model to do just that.
Maintaining Access Where Needed, and Restricting it Everywhere Else
By their very nature, enterprise cloud native environments are bound to involve multiple teams, with team members that have different roles, from developers to cloud ops or SREs, to security operations, vulnerability management, and compliance officers. Each role should have different permissions, but at the same time, teams should have access or visibility based on their specific projects and security level. This applies to everything from CI pipelines and individual images to clusters or namespaces within Kubernetes.
For example, developers are expected to fix vulnerabilities in their code, so they need to be notified and given access to that information. On the other hand, they should not be able to acknowledge and accept the risk of a vulnerability unilaterally – this should be left to security specialists who then should acknowledge vulnerabilities only within their domain and scope of responsibilities. But some teams, such as the corporate security team, need the ability to set global policies and aggregate security events data.
As good as all that might sound, deploying entirely separate security systems for each team is impractical and grossly inefficient – we need something more practical. Segregation of Duties (SoD) is a necessity in any security strategy and a requirement in many compliance regulations. To do this, we need to enable hierarchies and role-based permissions, and then apply them to defined scopes (including all aspects of what might be defined as “an application”). This is what Aqua’s multi-application RBAC does.
Limited Access, Not Limited Productivity or Flexibility
Our new multi-tenant, role-based access control (RBAC) capability allows you to segregate different projects or applications to limit access by assignments. This approach is powerful but also flexible to maintain productivity, support all types of deployment, security, and organizational structures.
The SoD is organized around Users, Roles, Permissions Sets, and Application Scopes.
The combination of these components offers a highly adaptable model. It allows admins to set scopes that could essentially encompass all aspects of an application. Then it takes granular permissions (such as read-only or edit access to an asset or a capability), which can be assigned to roles. Finally, specific users are given one or more roles – and this would typically be mapped from LDAP or Active Directory groups, no need to define security groups or roles for users from scratch.
Multi-Application Role-Based Access Control in Action
Let’s assume that an organization has two teams, one running a CRM application and another an eCommerce application, each using a separate registry. The eCommerce application is running in a separate cluster, and the CRM application is running within a Namespace inside a different cluster. The teams have internal stakeholders who require certain permissions and external stakeholders that have a global OOTB scope with full or partial permissions, and a manager that needs visibility into both environments.
Typical stakeholder roles include Developers who can view workloads, risks, and policies relevant to their application, but cannot edit them or view audit events; Application Managers who view workloads, risks, and policies relevant to the application and can edit them as well as view audit events; Cloud Ops personnel who will want to view K8s compliance information but can’t view vulnerabilities or security policies; And lastly, SecOps Admins who need to view all the resources in the system (OOTB user).
To define access and permissions for these disparate roles using Aqua is simple. Start by defining the permission sets, setting the application scope for each application, and then defining the roles which combine the permission set and application scope – this subsequently defines the permissions and their scope. With those steps completed, users are then assigned to roles. The Aqua console would now display information to those users based only on their assigned roles. We provide many default roles, but they can also be completely customized or created from scratch.
Summary
Modern enterprise environments are complex, consisting of multiple teams working on different projects and applications. To keep application teams sane and effective, but at the same time allow your CISO to sleep at night and avoid excessive permissions that could result in breaches or attacks, those teams must have access that’s restricted only to their relevant applications, role, and level. This means that each user should have visibility only into the resources (artifacts, workloads, and infrastructure) that she works on, relevant security risks (vulnerabilities and runtime events) that she needs to address, and be allowed read or write access to security policies based only on her role.
Working to secure many of the world’s largest cloud native deployments in the Global 1000 over the past few years, has enabled us here at Aqua to understand these complexities and develop a comprehensive model for secure RBAC in large, multi-application and multi-team environments.
