In this blog post, my colleague Tim Bardzil highlighted the benefits of enabling application teams to manage micro-segmentation for their respective applications. Delegating policy authoring comes with a complex set of challenges, which includes balancing the needs of application owners around visibility with the needs of security teams around enforcement of least privilege or Zero Trust. One of the fundamental pieces of technology that can solve this unique challenge is role-based access control (RBAC). While RBAC as a technology has been around for a while, integrating it with micro-segmentation requires an innovative approach.
Here are four capabilities that highlight our approach and are key to enabling application owners to be successful at micro-segmentation with Illumio:
1. Label-based RBAC
To implement role-based access for micro-segmentation, we developed a label-based method to delegate permissions. Using labels to assign permissions offers the most flexibility for organizations. What makes label-based RBAC powerful is its simplicity and extensibility. Labels have proven to be an effective tool to write segmentation policy. With label-based RBAC, organizations can assign user permissions using the same labels that are used to write micro-segmentation policies. Resources can be labeled along multiple dimensions such as Application, Environment, and Location. In the example below, a user is assigned permissions to the SAP application in the Production environment within the California data center. This user can then write label-based policies for the assigned application.
Label-based permissions for app owners
2. App owner persona-driven RBAC
Illumio offers two types of roles for RBAC: global and scoped. Global roles apply assigned permissions globally while scoped roles allow administrators to delegate permissions by scopes, which are defined using labels – and designed with application owners in mind.
We provide the following roles by which organizations can enable a variety of application owner personas to manage segmentation.
- Ruleset Manager: This role is the equivalent of an application owner tasked with building policy. Organizations can delegate policy writing privileges based on labels. Ruleset managers gain visibility into segmentation maps and traffic flows for their application, which simplifies policy writing. Ruleset Managers can also use Policy Generator to automatically generate policy for their applications.
- Ruleset Provisioner: This is the equivalent of an application owner tasked with reviewing and provisioning policy. It enables organizations to segregate policy writing from policy review and provisioning, allowing different users to be tasked with managing policy versus provisioning.
- Ruleset Viewer: This is a read-only role where the read permissions can be constrained to a specific application scope using labels.
- Workload Manager: This role allows organizations to enable workload operators who are tasked with labeling workloads, modifying workload properties, and even changing policy state on workloads.
Roles mapped to different app owner personas
3. Layered approach
We have seen many variations in what organizations need to enable different use cases for application owners. There is no “one size fits all” role. So, we have taken a layered approach, allowing organizations to stack permissions for application owners using one or more roles. As an example, imagine an application owner who has full permissions to write policies in a staging environment. That same application owner may not be allowed to write policies in the production environment and may be restricted to be a viewer. With our building blocks approach, customers can assign Ruleset Manager for this user in staging and Ruleset Viewer to the same user in production. This allows the same user to have different permissions across different application environments.
Stacked permissions for a single app owner allowing varying levels of access to multiple applications
4. 1-hop visibility
Enforcing least privilege restricts access to only the information users need. But application owners managing security policies need limited visibility that extends beyond the boundary of their applications. One example is building policies based on cross-application flows. Writing effective policy requires that an application owner gains visibility into the remote side of a traffic flow. Illumio’s RBAC allows application owners to get enough visibility into the remote endpoint so that they can write effective policy.
Limited 1-hop visibility for app owners into connected applications
Another example is policy visibility. Often, applications require policies to be written in an upstream application or core service. With App Owner View, Illumio allows application owners to get enough visibility into the far side policy so that they get a complete picture of what policies are in play to enable their application.
Limited 1-hop visibility for app owners into rules related to their applications
Balancing the visibility needs of application teams with the needs of security teams to comply with enforcement of least privilege requires role-based access that is built for micro-segmentation. Illumio makes it easy for organizations to allow their application teams to assist with micro-segmentation for their apps, helping organizations achieve Zero Trust. Our innovative approach is unique in the simplicity, security, and flexibility it offers both security teams and application owners to be successful at micro-segmentation.
For more on our approach:
- Read our Design Guide for more on our label-based policy model.
- Learn more about how app owners review flows and author policies through Policy Generator.
- Try it yourself – check out our 30-day free trial.
