Requesting Access
How to request access to Kubernetes permissions, roles, and resources through the P0 bot
Last updated
How to request access to Kubernetes permissions, roles, and resources through the P0 bot
Last updated
This topic describes how to request access to a Kubernetes cluster using P0's Slack bot. It contains the following sections:
To request access using the Slack bot:
Open Slack and send /p0 request as a Slack message in any direct message (DM) or Slack channel. This opens the P0 request modal:
In the popup, set Resources to Kubernetes, specify the cluster name, and populate the remaining fields with the specific access you want to request.
cluster-admin
admin
edit
view
By default, you can request all resources except system resources, such as objects in the kube-system namespace. The same applies to roles, however, you can request the following pre-defined Kubernetes cluster roles:
Click Request to initiate the request process. The Slack bot will:
Generate a message confirming your request creation.
Send a message to the approvers in the Slack channel designated by your organization's admin.
The following describes how P0 handles different scenarios:
If your request is approved, the Slack bot generates a message in the p0-requests Slack channel, indicating your access has been granted, and when it will expire.
If you are on-call (on a PagerDuty schedule) and your organization’s admin has enabled PagerDuty routing, your access may be automatically approved for one hour.
Your request must be approved or denied by an authorized member of your organization. Once approved or denied, you will have options to change / update your request within the P0 Security Slack DM.
On occasion you may run into request errors, and the bot will notify you during your request.
To learn more see the following subsections:
After your request is approved, the Slack bot displays a Relinquish button within the P0 Security Slack DM, with a link to the original p0-requests channel. You can use this button to remove your access early, if you complete use prior to the expiration date.
This revokes the access, and you must make a new request if you need it again.
Once access expires (either through timing out, or via the Relinquish button), the Slack bot sends an expiration message from the P0 Security app Slack DM and the p0-requests channel.
You may re-request the same access using the Request Access button, if you need to extend your session.
If your request is denied, the Slack bot sends a message from the P0 Security Slack DM and the p0-requests channel, indicating the reason for denial.
Example from the P0 Security Slack DM:
Example from the p0-requests channel:
If there is an error with your request, due to prerequisite permissions issues, the Slack bot sends a message from the P0 Security Slack DM and the p0-requests channel, indicating the reason for the error.
Example from the P0 Security Slack DM:
Example from the p0-requests channel:
When a request is approved, P0 creates a temporary cluster role from the role's rules that apply to the selected resource. This cluster role is then assigned to the requestor with one of the following:
Cluster role binding (if the resource is a cluster-level resource or the request applies to all namespaces)
Namespaced role binding (If the resource is in a specific namespace)
The following screenshot shows how to request the view cluster role and Deployments / default / nginx-deployment resource with read access to the nginx-deployment in the default namespace.
Upon approval of this request P0, creates a cluster role and role binding.
The generated role contains all the rules from the view cluster role that apply to a deployment resource, restricted only to nginx-deployment:
The generated namespaced role binding links the cluster role to the requestor john.smith@company.com:
If the Kubernetes cluster is hosted on AWS EKS, then P0 also modifies the aws-auth ConfigMap object to map the user ARN to the Kubernetes user john.smith@company.com.
