Lab 15.2
Lab 15.2
Kubernetes clusters have two types of users service accounts and normal users, but normal users are assumed
to be managed by an outside service. There are no objects to represent them and they cannot be added via an API
call, but service accounts can be added.
We will use RBAC to configure access to actions within a namespace for a new contractor, Developer Dan who will be
working on a new project.
1. Create two namespaces, one for production and the other for development.
2. View the current clusters and context available. The context allows you to configure the cluster to use, namespace and
user for kubectl commands in an easy and consistent manner.
4. Generate a private key then Certificate Signing Request (CSR) for DevDan. On some Ubuntu 18.04 nodes a missing file
may cause an error with random number generation. The touch command should ensure one way of success.
5. Using thew newly created request generate a self-signed certificate using the x509 protocol. Use the CA keys for the
Kubernetes cluster and set a 45 day expiration. You’ll need to use sudo to access to the inbound files.
6. Update the access config file to reference the new key and certificate. Normally we would move them to a safe directory
instead of a non-root user’s home.
student@lfs458-node-1a0a:˜$ kubectl config set-credentials DevDan \
--client-certificate=/home/student/DevDan.crt \
--client-key=/home/student/DevDan.key
User "DevDan" set.
7. View the update to your credentials file. Use diff to compare against the copy we made earlier.
student@lfs458-node-1a0a:˜$ diff cluster-api-config .kube/config
16a,19d15
> - name: DevDan
> user:
> as-user-extra: {}
> client-certificate: /home/student/DevDan.crt
> client-key: /home/student/DevDan.key
8. We will now create a context. For this we will need the name of the cluster, namespace and CN of the user we set or
saw in previous steps.
student@lfs458-node-1a0a:˜$ kubectl config set-context DevDan-context \
--cluster=kubernetes \
--namespace=development \
--user=DevDan
Context "DevDan-context" created.
9. Attempt to view the Pods inside the DevDan-context. Be aware you will get an error.
student@lfs458-node-1a0a:˜$ kubectl --context=DevDan-context get pods
Error from server (Forbidden): pods is forbidden: User "DevDan"
cannot list pods in the namespace "development"
11. Again check the recent changes to the cluster access config file.
student@lfs458-node-1a0a:˜$ diff cluster-api-config .kube/config
<output_omitted>
12. We will now create a YAML file to associate RBAC rights to a particular namespace and Role.
role-dev.yaml
1 kind: Role
2 apiVersion: rbac.authorization.k8s.io/v1
3 metadata:
4 namespace: development
5 name: developer
6 rules:
7 - apiGroups: ["", "extensions", "apps"]
8 resources: ["deployments", "replicasets", "pods"]
9 verbs: ["list", "get", "watch", "create", "update", "patch", "delete"]
10 # You can use ["*"] for all verbs
13. Create the object. Check white space and for typos if you encounter errors.
student@lfs458-node-1a0a:˜$ kubectl create -f role-dev.yaml
role.rbac.authorization.k8s.io/developer created
14. Now we create a RoleBinding to associate the Role we just created with a user. Create the object when the file has
been created.
student@lfs458-node-1a0a:˜$ vim rolebind.yaml
rolebind.yaml
1 kind: RoleBinding
2 apiVersion: rbac.authorization.k8s.io/v1
3 metadata:
4 name: developer-role-binding
5 namespace: development
6 subjects:
7 - kind: User
8 name: DevDan
9 apiGroup: ""
10 roleRef:
11 kind: Role
12 name: developer
13 apiGroup: ""
15. Test the context again. This time it should work. There are no Pods running so you should get a response of No
resources found.
student@lfs458-node-1a0a:˜$ kubectl --context=DevDan-context get pods
No resources found in development namespace.
17. We will now create a different context for production systems. The Role will only have the ability to view, but not create
or delete resources. Begin by copying and editing the Role and RoleBindings YAML files.
student@lfs458-node-1a0a:˜$ cp role-dev.yaml role-prod.yaml
role-prod.yaml
1 kind: Role
2 apiVersion: rbac.authorization.k8s.io/v1
3 metadata:
4 namespace: production #<<- This line
5 name: dev-prod #<<- and this line
6 rules:
7 - apiGroups: ["", "extensions", "apps"]
8 resources: ["deployments", "replicasets", "pods"]
9 verbs: ["get", "list", "watch"] #<<- and this one
rolebindprod.yaml
1 kind: RoleBinding
2 apiVersion: rbac.authorization.k8s.io/v1
3 metadata:
4 name: production-role-binding #<-- Edit to production
5 namespace: production #<-- Also here
6 subjects:
7 - kind: User
8 name: DevDan
9 apiGroup: ""
10 roleRef:
11 kind: Role
12 name: dev-prod #<-- Also this
13 apiGroup: ""
20. Verify that user DevDan can view pods using the new context.
23. Experiment with other subcommands in both contexts. They should match those listed in the respective roles.