Requesting Access
Last updated
Last updated
Open up the p0 modal using /p0 request and select "Kubernetes" as the resource.
Choose "Kubernetes resource" as the "Access type".
Select a "Resource" and a "Role" using the auto-complete fields. By default, all resources can be requested except system resources - such as objects in the "kube-system" namespace. The same applies to roles, however, the "cluster-admin", "admin", "edit", and "view" predefined Kubernetes cluster roles can be requested.
Provide a "reason" why the access is needed. Click "Request".
Once you make the request, you should get a Slack message from the p0 bot showing your request. There will also be a message to the approvers in the Slack channel designated by your org admin, requesting access.
If your request is approved, when you get a message that it has been approved, that means you should already have access provisioned, as that happens all at the same time.
If you are on-call (on a PagerDuty schedule), and your org admin has enabled PagerDuty routing, your access may be automatically approved for 1 hour.
After your request is approved, there will be a “relinquish” button for you to let go of your permissions early if you finish what you wanted to do before the expiration date (so you can let go of unneeded permissions).
If you wait for the access to expire, you will get a message that it has expired once it does.
If your request is denied, you'll get a message letting you know.
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
A request for the cluster role "view" and resource "Deployments / default / nginx-deployment" grants 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 cluster role "view" that apply to a Deployment resource kind, 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 will additionally modify the "aws-auth" ConfigMap object to map the user ARN to the Kubernetes user "john.smith@company.com".
