Requesting Access

Requesting from Slack

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".

What happens next

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.

1. 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.

2. 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.

3. 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).

4. If you wait for the access to expire, you will get a message that it has expired once it does.

5. If your request is denied, you'll get a message letting you know.

How it works

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

Example

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":

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2077-08-19T22:01:29Z"
  name: p0-view-Deployments-VpL5aQZpWnNqMnkrzze2
  resourceVersion: "425167"
  uid: 0592ea64-c146-4bcd-9da0-86b6f32829f4
rules:
- apiGroups: [apps]
  resourceNames: [nginx-deployment]
  resources: [deployments]
  verbs: [get, list, watch]
- apiGroups: [extensions]
  resourceNames: [nginx-deployment]
  resources: [deployments]
  verbs: [get, list, watch]

The generated namespaced role binding links the cluster role to the requestor "[e-mail]":

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2077-08-19T22:01:29Z"
  name: p0-view-Deployments-VpL5aQZpWnNqMnkrzze2-binding
  namespace: default
  resourceVersion: "425168"
  uid: c0a5ea14-1e6f-4be1-9d95-4b9ed2e816d7
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: p0-view-Deployments-VpL5aQZpWnNqMnkrzze2
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: [e-mail]

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 "[e-mail]".

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::123456789000:role/eksNodeRole
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - userarn: arn:aws:iam::123456789000:user/[e-mail]
      username: [e-mail]
kind: ConfigMap
metadata:
  creationTimestamp: "2077-08-17T21:34:09Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "425175"
  uid: b8f1173b-f6b2-4cdd-bd36-6adee577ed2a