Grant Port Forward On Some Namespaces
This example walks you through defining a ClusterRole and an EscalationPolicy that allows your user to temporarily
get the port-forward permission on two different namespaces.
First, let’s define a ClusterRole that grants the create pods/portforward permission.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: port-forwarder
rules:
- apiGroups: [""]
resources: ["pods/portforward"]
verbs: ["create"]
Defining a cluster role by itself doesn’t do much. Let’s define an EscalationPolicy to allow our users to use this new-role.
apiVersion: k8s.kudo.dev/v1alpha1
kind: EscalationPolicy
metadata:
name: gain-port-forward
spec:
subjects:
- kind: Group
name: system:authenticated # All the authenticated users.
challenges:
- kind: PeerReview
reviewers:
- kind: Group
name: admin@my-company.io
target:
defaultDuration: 60m
maxDuration: 4h
grants:
- kind: KubernetesRoleBinding
defaultNamespace: application-a
allowedNamespaces:
- application-a
- application-b
roleRef:
kind: ClusterRole
name: port-forwarder
apiGroup: rbac.authorization.k8s.io
Let’s review the configuration, This EscalationPolicy call gain-port-forward translates to the following statements:
- The
subjectssection tells that all theauthenticatedusers are allowed to escalate using this policy - The
challengessections tells that an escalation using this policy must be approved by one member of the groupadmin@my-company.io - The
targetsections defines what the escalation actually grants:- Kudo will create a
RoleBindingbetween the requestor and the roleport-forwarderby default in theapplication-anamespace, but is allowed to be used in theapplication-aandapplication-bnamespace. - The escalation lasts 60 minutes by default, but users can ask up to 4h.
- Kudo will create a
From there, you can escalate using this policy using kudo kubectl plugin:
kubectl kudo escalate gain-port-forward --namespace application-b --reason "need to debug application B, ticket #3939"