Use the kubectl create clusterrole command to create the Role imperatively:
$ kubectl create clusterrole service-view --verb=get,list \
--resource=services
If you’d rather start with the YAML file, use content shown in the file service-view-clusterrole.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: service-viewrules:- apiGroups: [""] resources: ["services"] verbs: ["get", "list"]
Create the ClusterRole from the YAML file:
$ kubectl apply -f service-view-clusterrole.yaml
Use the kubectl create rolebinding command to create the RoleBinding imperatively:
$ kubectl create rolebinding ellasmith-service-view --user=ellasmith \
--clusterrole=service-view -n development
The declarative approach of the RoleBinding could look like the one in the file ellasmith-service-view-rolebinding.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: ellasmith-service-view namespace: developmentroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: service-viewsubjects:- kind: User name: ellasmith apiGroup: rbac.authorization.k8s.io
Create the RoleBinding from the YAML file:
$ kubectl apply -f ellasmith-service-view-rolebinding.yaml
Use the kubectl create clusterrole command to create the ClusterRole imperatively:
$ kubectl create clusterrole combined \
--aggregation-rule="rbac.cka.cncf.com/aggregate=true"
If you’d rather start with the YAML file, use content shown in the file combined-clusterrole.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: combinedaggregationRule: clusterRoleSelectors: - matchLabels: rbac.cka.cncf.com/aggregate: "true"rules: []
Create the ClusterRole from the YAML file:
$ kubectl apply -f combined-clusterrole.yaml
Rendering the rules shows an empty list as no ClusterRoles were selected by label selection:
$ kubectl describe clusterrole combined
Name: combined
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
Use the kubectl create clusterrole command to create the ClusterRole imperatively. The command does not provide an option for adding a label. Therefore, generating the YAML manifest using the dry-run option is a good start:
$ kubectl create clusterrole deployment-modify \
--verb=create,delete,patch,update --resource=deployments \
--dry-run=client -o yaml > deployment-modify-clusterrole.yaml
Modify the content shown in the file deployment-modify-clusterrole.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: deployment-modify labels: rbac.cka.cncf.com/aggregate: "true"rules:- apiGroups: ["apps"] resources: ["deployments"] verbs: ["create", "delete", "patch", "update"]
Create the ClusterRole from the YAML file:
$ kubectl apply -f deployment-modify-clusterrole.yaml
Rendering the rules for the Clusterrole combined lists the rules defined by the ClusterRole deployment-modify:
$ kubectl describe clusterrole combined
Name: combined
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
deployments.apps [] [] [create \
delete patch update]
Listing Services is allowed for the user ellasmith in the namespace development. This is taken care by RoleBinding ellasmith-service-view:
$ kubectl auth can-i list services --as=ellasmith --namespace=development
yes
Write the output the file list-services-ellasmith.txt.
$ echo 'yes' > list-services-ellasmith.txt
Watching Deployments is not allowed for the user ellasmith in the namespace production. The ClusterRole named deployment-modify only allows the verbs create, delete, patch, and update.
$ kubectl auth can-i watch deployments --as=ellasmith --namespace=production
no
Write the output the file watch-deployments-ellasmith.txt.
$ echo 'no' > watch-deployments-ellasmith.txt
Deployments are allowed to be created, deleted, patched, and updated.
First, create the namespace named apps. Then, we’ll create the ServiceAccount:
$ kubectl create namespace apps
$ kubectl create serviceaccount api-access -n apps
Alternatively, you can use the declarative approach. Create the namespace from the definition in the file apps-namespace.yaml:
apiVersion: v1kind: Namespacemetadata: name: apps
Create the namespace from the YAML file:
$ kubectl apply -f apps-namespace.yaml
Create a new YAML file called api-serviceaccount.yaml with the following contents:
apiVersion: v1kind: ServiceAccountmetadata: name: api-access namespace: apps
Run the apply command to instantiate the ServiceAccount from the YAML file:
$ kubectl create -f api-serviceaccount.yaml
Use the create clusterrole command to create the ClusterRole imperatively:
$ kubectl create clusterrole api-clusterrole --verb=watch,list,get \
--resource=pods
If you’d rather start with the YAML file, use content shown in the file api-clusterrole.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: api-clusterrolerules:- apiGroups: [""] resources: ["pods"] verbs: ["watch","list","get"]
Create the ClusterRole from the YAML file:
$ kubectl apply -f api-clusterrole.yaml
Use the create clusterrolebinding command to create the ClusterRoleBinding imperatively.
$ kubectl create clusterrolebinding api-clusterrolebinding \
--serviceaccount=apps:api-access --clusterrole=api-clusterrole
The declarative approach of the ClusterRoleBinding could look like the one in the file api-clusterrolebinding.yaml:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: api-clusterrolebindingroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: api-clusterrolesubjects:- apiGroup: "" kind: ServiceAccount name: api-access namespace: apps
Create the ClusterRoleBinding from the YAML file:
$ kubectl apply -f api-clusterrolebinding.yaml
Execute the run command to create the Pods in the different namespaces. You will need to create the namespace rm before you can instantiate the Pod disposable:
$ kubectl run operator --image=nginx:1.21.1 --restart=Never \
--port=80 --serviceaccount=api-access -n apps
$ kubectl create namespace rm
$ kubectl run disposable --image=nginx:1.21.1 --restart=Never \
-n rm
The following YAML manifest shows the rm namespace definition stored in the file rm-namespace.yaml:
apiVersion: v1kind: Namespacemetadata: name: rm
The YAML representation of those Pods stored in the file api-pods.yaml could look as follows:
apiVersion: v1kind: Podmetadata: name: operator namespace: appsspec: serviceAccountName: api-access containers: - name: operator image: nginx:1.21.1 ports: - containerPort: 80---apiVersion: v1kind: Podmetadata: name: disposable namespace: rmspec: containers: - name: disposable image: nginx:1.21.1
Create the namespace and Pods from the YAML files:
$ kubectl create -f rm-namespace.yaml
$ kubectl create -f api-pods.yaml
Determine the API server endpoint and the Secret access token of the
ServiceAccount. You will need this information for making the API calls:
$ kubectl config view --minify -o \
jsonpath='{.clusters[0].cluster.server}'
https://192.168.64.4:8443
$ kubectl get secret $(kubectl get serviceaccount api-access -n apps \
-o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' -n apps \
| base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6Ii1hOUhI...
Open an interactive shell to the Pod named operator:
$ kubectl exec operator -it -n apps -- /bin/sh
Emit API calls for listing all Pods and deleting the Pod disposable living in the rm namespace. You will find that while the list operation is permitted, the delete operation isn’t:
# curl https://192.168.64.4:8443/api/v1/namespaces/rm/pods --header \
"Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ii1hOUhI..." \
--insecure
{
"kind": "PodList",
"apiVersion": "v1",
...
}
# curl -X DELETE https://192.168.64.4:8443/api/v1/namespaces \
/rm/pods/disposable --header \
"Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ii1hOUhI..." \
--insecure
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "pods \"disposable\" is forbidden: User \
\"system:serviceaccount:apps:api-access\" cannot delete \
resource \"pods\" in
API group \"\" in the namespace \"rm\"",
"reason": "Forbidden",
"details": {
"name": "disposable",
"kind": "pods"
},
"code": 403
}
