Security features for Kubernetes

The P0 integration grants temporary access to sensitive Kubernetes resources. A sensitive resource carries a risk for the company if it falls into the wrong hands. As such, the entire infrastructure of the production environment is sensitive. Secrets, data, computing and memory resources in production are typically resources that internal stakeholders do not have constant access to.

‍

P0 automates privilege escalations so the team can do their work with minimal friction while improving the security posture. This post describes how the integration works, and the security features P0 implemented to protect customer accounts.

Architecture

When an access request is approved, P0 creates the necessary roles and role bindings for the requestor inside the Kubernetes cluster, by calling the appropriate Kubernetes RBAC API endpoints. This grants access instantly, without emptying cached tokens and re-login. Upon expiry, P0 undoes the changes. The state of access requests, and when to expire them, is tracked on P0’s servers. The integration is purely API-based. However, if the Kubernetes cluster is private, P0 uses a reverse proxy to establish a connection.

Authentication

P0 uses a Kubernetes service account identity with a long-lived service account token that is stored encrypted on P0’s servers. This access token can be revoked by the organization unilaterally at any time by deleting the Kubernetes service account or secret object.

‍

Authorization

P0 has two types of access in the Kubernetes cluster:

1. List resourcesP0 creates an inventory of requestable resources and verifies if the requested resource exists

2. Change RBACCreate roles and role bindings to grant access to requestors

‍

Permission boundary

The permission boundary ensures that if P0 is compromised the attacker cannot gain more permissions in the customer’s Kubernetes cluster than originally granted to P0.

This prevents lateral movement in Kubernetes and restricts the blast radius to reconnaissance and changing RBAC for other principals. An attacker cannot exfiltrate data, encrypt data, or create backdoor access unless they also compromised another account in the customer’s environment.

Let’s examine the escalation paths of the P0 service account. An attacker would be able to expand their foothold in the customer’s account in the following three ways:

‍

1. Create another service account, or other authenticated user - for instance using client certificate authentication - that they can escalate. some text
   1. This is prevented because the P0 service account doesn’t have permission to create anything except roles and role bindings.

2. Reading tokens of other service accounts stored in the system as secret objectssome text
   1. Prevented for the same reason as above - P0 service account cannot read the contents of secrets.

3. Adding more permissions to the P0 service account they can already accesssome text
   1. If P0 is able to change roles and role bindings of any principal it could add more permissions to itself. In Kubernetes, adding permissions that one does not have is gated behind the “bind” and “escalate” verbs. P0 is allowed to perform both, however, a custom admission controller that is deployed with P0 prevents binding and escalating itself. The admission controller runs as a Kubernetes service. It inspects all API requests that attempt to modify roles / role bindings and denies requests that come from the P0 service account and attempt to modify its own permissions.

Connectivity

Kubernetes API endpoints are often private. In order to integrate with private clusters, P0 uses the braekhus reverse proxy, which may run inside or outside the cluster. This proxy app must be able to:

• Access to the Kubernetes API endpoint

• Access the internet - only in the egress (outgoing) direction

The proxy initiates a secure WebSocket connection to P0’s servers. P0 sends Kubernetes API payloads over the WebSocket tunnel, which the proxy forwards to the cluster. The authentication header originates from P0’s backends and is forwarded to the Kubernetes API. The reverse proxy is a simple HTTP request forwarder, without any domain knowledge of Kubernetes.

To dive deeper into P0 Security, explore our guided tour of privilege escalation workflows here, or refer to our detailed docs. You can also join our community Slack channel to engage with like-minded users.