Security Policy Self-Service for Developers and DevOps Teams

In today’s economy, digital assets (applications, data, and processes) determine business success. Cloud-native applications are designed to iterate rapidly, creating rapid time-to-value for businesses. Organizations that are able to rapidly build and deploy their applications have significant competitive advantage. To this end, more and more developers are creating and leading DevOps teams that not only drive application development, but also take on operational responsibilities formerly owned by platform and security teams.

What’s the Value of a Self-Service Approach?

Cloud-native applications are often designed and deployed as microservices. The development team that owns the microservice understands the behavior of the service, and is in the best position to define and manage the network security of their microservice. A self-service model enables developers to follow a simple workflow and generate network policies with minimal effort. When problems occur with. application connectivity, developers should be able to diagnose connectivity issues and resolve them quickly without having to depend on resources outside of the team.

Developers and DevOps teams can also take a leading role in managing security, which is an integral part of cloud-native applications. There are two aspects to security in the context of Kubernetes.

• Cluster security – is a uniform set of policies that apply to all applications running in the cluster, e.g., scanning, attestation, admission controls, pod security, run-time monitoring, cluster-wide network policies, etc.
• Application security – the set of policies that apply to an application, e.g., network policy, application-specific alerting, etc. We will primarily focus on network policy for the remainder of this post.

Requirements for a Self-Service Environment

Cloud-native culture – In the cloud-native world, Development, DevOps, and SRE teams must work in unison.

• Solutions and processes should enable developers and DevOps teams to apply network policies to secure their services and provide access to other endpoints, for example.
• Developers should have access to all the logs and reports pertaining to their service for faster troubleshooting.

Compliance boundaries – All business applications are subject to specific compliance requirements regarding firewall controls.

• Typically, these controls apply to the entire organization and are agnostic to specific workloads running in the cloud or on-prem.
• Security and compliance teams should be able to enforce role boundaries to prevent developers from overriding compliance controls.

Developer-friendly products and processes – As organizations move from siloed operations to cloud-native, products and processes should support granular role-based access control (RBAC) that integrates with the infrastructure tooling.

• Any developer or service on-boarding should be a self-service with approval controls.
• The developer experience should be simple enough to not distract focus on the business of building products.
• Solutions and processes should make it easy to visualize who-can-do-what without getting lost in a maze of code/screens.

How does Self-Service Work in Calico Enterprise?

Calico Enterprise has operationalized the concept of policy tiers, which support delegation of authority by organizational structure and area of responsibility (Platform, Security, DevOps, Default). An example of tiered policy structure is shown below.

With this approach, you can create your own tiers and customize permissions based on your organizational structure. Calico Enterprise ensures that the policies in the left-most tiers are given precedence over the right. Tiers are a Kubernetes object, so you can control who can view/modify policies in specific tiers. Every change of record to tiers and policies is captured, enabling you or auditors to go back in time for review or troubleshooting purposes.

Developers have access to their policies in Calico Enterprise. However, creating policies to lock down an application is not easy. Calico Enterprise simplifies the process for developers and DevOps teams, enabling them to manage the entire policy workflow.

• Use the policy recommendation feature in Calico Enterprise to automatically generate a policy based on historical traffic patterns for your service.

• Use the policy preview to see the impact of the policy before it is enforced.

• Download the YAML to apply through the GitOps pipeline, or apply directly without fear of impacting traffic using the Policy Staging function of Calico Enterprise.
• Once you are confident that the policy will work as intended, you can apply it by clicking on “Enforce”.

• Troubleshooting application connectivity in distributed computing environments is hard. The Flow Visualizer in Calico Enterprise, shown below, is a highly-effective, easy-to-use tool for troubleshooting your services. If there’s an unexpected issue, you can quickly pin-point the policies responsible for denying the traffic. Access can be restricted using RBAC so that Developers have access to only the data for their services.

Finally, Calico Enterprise collects a rich set of logs (flow, audit, DNS) and makes them available through a Kibana interface. You can create individual user credentials in Kibana that restrict access to service logs to specific individuals or groups.

Why Use Self-Service?

• Accelerate deployment of new capabilities – In the past, policy updates occurred within a limited time window (e.g., over the weekend). All policy changes would be consolidated using a ticketing workflow and someone from a centralized IT team would apply the policies in the given window. If things went wrong, they would revert the policy changes. In the cloud-native world, you can offload the controls to developers, enabling them to make changes as and when appropriate. This eliminates friction and streamlines the process.
• Enable faster time-to-repair – By giving developers access to all the logs for their services, you empower them to diagnose connectivity issues in real time and avoid the lengthy delays incurred by developers as they wait for access to service logs.

How to Enable Self-Service?

Start with defining the access blueprint for policies and logs. This should be part of your overall cloud security blueprint. Next, translate the blueprint into Kubernetes and Calico Enterprise specific tiers, roles and role bindings. Then you can enforce access controls based on roles and structure. Define your policy management process, which should include an approval workflow. We find the GitOps workflow to be the most widely used among Tigera’s customer base. Here’s a sample workflow.

Additionally, check out these resources and working samples…

• Policy Tiers
• Policy Recommendation
• Policy Preview
• Staged Network Policies
• Flow Visualization
• Logs in Calico Enterprise

————————————————-
Free Online Training
Access Live and On-Demand Kubernetes Training

Calico Enterprise – Free Trial
Network Security, Monitoring, and Troubleshooting
for Microservices Running on Kubernetes