Service based access control with Sysdig Secure Teams.

While you’re likely familiar with role-based access control, Sysdig teams introduce the concept of service-based access control. With service-based access control, administrators can define groups of users that have access to policy events, policy configuration, and scanning data limited to a service or set of services, as defined by your orchestration system (think Kubernetes, Mesos, and the like). You might be asking, “Why is this important?” And you should be. Our answer is: Because this is the way your organization wants to work. Service-based access control is ideal to reduce the exposure of data to those who actually need it, and also makes users more productive through focusing them on data that is relevant to them. Your platform team is thinking about how to support these development teams, and enable self-service for them, while at the same time keeping an eye on the entire operation. Your SecOps team is looking to isolate access to data while not impeding developer productivity. That’s a lot of demands, all at once, and service-based access control can address them. Before we describe Teams in more detail, let’s take a look what our beta users did with this functionality.

Security scenarios for Teams: Microservices, Kubernetes, compliance, and more

We’ve been happy to see a large number of potential uses for teams appear as customers tested this new functionality with us. Here’s a quick review of what we’ve heard so far.

• The classic “dev vs prod” split: Many organizations prefer to limit the number of people accessing data related to their production services. This is about isolating physical infrastructure and the applications on top.
• Microservices where each team needs to only see their own dashboards and field its own alerts: By scoping down the data accessible to individual development teams and their related services, developers can more effectively focus on the information that is relevant to them. This is about building teams based on logical isolation using orchestration or config management metadata.
• Platform as a service where ops teams need to see the entire platform: This is somewhat the flip of the previous use case, enabling certain people to see all data for all services as well as the underlying hardware. This is perfect for managed service providers who are managing a multi-tenant environments, or devops teams using a similar model within their own organization.
• Restricted environments: An even more specific use case of the microservices example to limit data access for security and compliance: Certain services, such as authentication and billing, may have a very specific set of individuals authorized to access them.
• Organizations or environments that need to segment incident response for efficiency: This is a wide ranging use case. We’ve seen very large organizations form teams just to simplify access; smaller organizations create ephemeral teams to troubleshoot a particular issue; or teams formed to optimize QA & support access to system data.

How to set up Sysdig Teams

To set up a team, you really need to just do two things:

1. Set the scope for a team based on orchestration metadata from Kubernetes, Mesos, and Swarm, as well as other characteristics of your environment.
2. Assign users to any number of teams based on the services or infrastructure they need access to.

Teams in action

Let’s take a look at how teams will change your experience with different areas of Sysdig Secure.

Vulnerability management & image scanning

The gif below starts off with a view that SecOPs users would use within Sysdig Secure. They can see every image that’s running in the environment and whether or not it’s passed its scanning policy evaluation. By switching to the Example-Java-App team which is scoped to kubernetes.namespace.name = Example-Java-App we can now see the view that developers of that team would experience when logging into Sysdig Secure. They can only see the images that roll up into pods, services, and deployments that are part of that namespace.

Policy creation

Policy creation is also limited to the entities that are within the scope of a team. Users of the Example-Java-App team can only apply policies to entities scoped below the Example-Java-App namespace within kubernetes. This gives App Developers and Service Owners the ability apply policy to the services they have created without impacting anything else in the infrastructure. In the image below we can see the only deployment scoping options available are the deployments within the namespace of the team. Here are some potential use cases app Developers could define for the services running within their namespace:

• Defining the images they expect to run within the namespace
• Defining the registry location that all images within that namespace should come from
• Defining which kubernetes deployments within their team should have inbound/outbound connections
• Defining which processes they’d expect to run within the images they have built that are deployed to that namespaces.

Other examples could include scheduling compliance tasks to run daily in some AWS regions and weekly in others, or allowing traditional security teams to write policies that apply to just hosts and not your kubernetes infrastructure.