Overview

In this lab, you will create namespaces within a GKE cluster, and then use role-based access control to permit a non-admin user to work with Pods in a specific namespace.

Objectives

In this lab, you learn how to perform the following tasks:

• Create namespaces for users to control access to cluster resources
• Create roles and RoleBindings to control access within a namespace

Note: For this lab, you have been provisioned with two user names available in the Connection Details dialog.

In this lab we will refer to these accounts as Username 1 and Username 2.

Task 1. Create namespaces for users to access cluster resources

Sign in to the Google Cloud Console as the first user

1. Sign in to the Google Cloud Console in an Incognito window as usual with the Username 1 provided in Qwiklabs. Note that both user names use the same password.
2. On the Google Cloud Console title bar, click Activate Cloud Shell ().
3. When prompted, click Continue.

You don't need to wait for the Cloud Shell to start, you can proceed to the next task immediately.

Note: Username 2 currently has access to the project, but only possesses the Viewer role, which makes all resources in the project visible, but read-only.

Sign in to the Google Cloud Console as the second user

1. Open another tab in your incognito window.
2. Navigate to console.cloud.google.com.
3. Click on the user icon in the top-right corner of the screen, and then click Add account.
4. Sign in to the Google Cloud Console with the Username 2 provided. Again, note that both user names use the same password.
5. On the Google Cloud Console title bar, click Activate Cloud Shell ().
6. When prompted, click Continue.

You don't need to wait for the Cloud Shell to start, you can proceed to the next task immediately.

Connect to the lab GKE cluster

1. Switch back to the Username 1 Google Cloud Console tab.

Note: Make sure you are on the Username 1 Google Cloud Console tab.

2. In Cloud Shell, type the following command to set the environment variable for the zone and cluster name:

export my_zone={{{ project_0.default_zone | ZONE }}} export my_cluster=standard-cluster-1

3. Configure tab completion for the kubectl command-line tool:

source <(kubectl completion bash)

4. Configure access to your cluster for kubectl:

gcloud container clusters get-credentials $my_cluster --zone $my_zone

5. In Cloud Shell, enter the following command to clone the lab repository to the lab Cloud Shell:

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

6. Create a soft link as a shortcut to the working directory:

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

7. Change to the directory that contains the sample files for this lab:

cd ~/ak8s/RBAC/

Create a namespace

A manifest file called my-namespace.yaml has been created for you that creates a new namespace called production.

apiVersion: v1 kind: Namespace metadata: name: production

1. List the current namespaces in the cluster using the following command:

kubectl get namespaces

Output:

NAME STATUS AGE default Active 17m kube-node-lease Active 17m kube-public Active 17m kube-system Active 17m

2. In the Cloud Shell, execute the following command to create the new namespace:

kubectl create -f ./my-namespace.yaml

3. Check if your namespace is there with the following command:

kubectl get namespaces

Output:

NAME STATUS AGE default Active 6m kube-node-lease Active 6m kube-public Active 6m kube-system Active 6m production Active 4s

Your new namespace appears at the bottom of the list.

4. You can view details of an existing namespaces by executing:

kubectl describe namespaces production

Output:

Name: production Labels: Annotations: Status: Active Resource Quotas Name: gke-resource-quotas Resource Used Hard -------- --- --- count/ingresses.extensions 0 100 count/jobs.batch 0 5k pods 0 1500 services 0 500 No LimitRange resource.

Create a resource in a namespace

If you do not specify the namespace of a Pod it will use the namespace ‘default'. In this task you specify the location of our newly created namespace when creating a new Pod. A simple manifest file called my-pod.yaml that creates a Pod that contains an nginx container has been created for you.

apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

1. In the Cloud Shell, execute the following command to create the resource in the namespace called production:

kubectl apply -f ./my-pod.yaml --namespace=production

Alternatively you could have specified the namespace in the yaml file. This requires the namespace: production field in the metadata: section.

For example:

apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx namespace: production spec: containers: - name: nginx image: nginx ports: - containerPort: 80

2. Try using the following command to view your Pod:

kubectl get pods

Output:

No resources found in default namespace.

You will not see your Pod because kubectl checked the default namespace instead of your new namespace.

3. Run the command again, but this time specify the new namespace:

kubectl get pods --namespace=production

Output:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 20s

Now you should see your newly created Pod.

Click Check my progress to verify the objective.

Create namespace and pod

Task 2. About roles and RoleBindings

In this task you will create a sample custom role, and then create a RoleBinding that grants Username 2 the editor role in the production namespace.

The role is defined in the pod-reader-role.yaml file that is provided for you. This manifest defines a role called pod-reader that provides create, get, list, and watch permission for Pod objects in the production namespace. Note that this role cannot delete Pods.

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: production name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list", "watch"]

Create a custom Role

Before you can create a Role, your account must have the permissions granted in the role being assigned. For cluster administrators this can be easily accomplished by creating the following RoleBinding to grant your own user account the cluster-admin role.

1. To grant the Username 1 account cluster-admin privileges, run the following command, replacing [USERNAME_1_EMAIL] with the email address of the Username 1 account:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user [USERNAME_1_EMAIL]

Output example:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user gcpstaging28307_student@qwiklabs.net

2. In the Cloud Shell, execute the following command to create the role:

kubectl apply -f pod-reader-role.yaml

3. To list the roles to verify it was created, execute the following command:

kubectl get roles --namespace production

Output:

NAME AGE pod-reader 3m

Create a RoleBinding

The role is used to assign privileges, but by itself it does nothing. The role must be bound to a user and an object, which is done in the RoleBinding.

The username2-editor-binding.yaml manifest file creates a RoleBinding called username2-editor for the second lab user to the pod-reader role you created earlier. That role can create and view Pods but cannot delete them.

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: username2-editor namespace: production subjects: - kind: User name: [USERNAME_2_EMAIL] apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

This file contains a placeholder, [USERNAME_2_EMAIL], that you must replace with the email address of Username 2 before your use apply it.

1. In the Cloud Shell create an environment variable that contains the full email address of Username 2:

export USER2=[USERNAME_2_EMAIL]

Output example:

export USER2=gcpstaginguser68_student@qwiklabs.net

2. In the Cloud Shell use sed to replace the placeholder in the file with the value of the environment variable:

sed -i "s/\[USERNAME_2_EMAIL\]/${USER2}/" username2-editor-binding.yaml

3. In the Cloud Shell, execute the following command to confirm that the correct change has been made:

cat username2-editor-binding.yaml

The subjects section should now look similar to the following.

Output example:

subjects: - kind: User name: gcpstaginguser68_student@qwiklabs.net apiGroup: rbac.authorization.k8s.io

You will apply this RoleBinding later.

Test access

Now you will test whether Username 2 can create a Pod in the production namespace by using Username 2 to create a Pod using the manifest file production-pod.yaml. This manifest deploys a simple Pod with a single nginx container.

apiVersion: v1 kind: Pod metadata: name: production-pod labels: name: production-pod namespace: production spec: containers: - name: production-pod image: nginx ports: - containerPort: 8080

Because this is a separate user account you need to prepare the Cloud Shell environment a second time so that you have access to the Cluster and the sample files from the lab repository.

1. Switch back to the Username 2 Google Cloud Console tab.

Note: Make sure you are on the Username 2 Google Cloud Console tab.

2. In Cloud Shell for Username 2, type the following command to set the environment variable for the zone and cluster name:

export my_zone={{{ project_0.default_zone | ZONE }}} export my_cluster=standard-cluster-1

3. Configure tab completion for the kubectl command-line tool:

source <(kubectl completion bash)

4. Configure access to your cluster for kubectl:

gcloud container clusters get-credentials $my_cluster --zone $my_zone

5. In Cloud Shell, enter the following command to clone the lab repository to the lab Cloud Shell:

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

6. Create a soft link as a shortcut to the working directory:

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

7. Change to the directory that contains the sample files for this lab:

cd ~/ak8s/RBAC/

8. Check if Username 2 can see the production namespace by using the following command:

kubectl get namespaces

Output:

NAME STATUS AGE default Active 29m kube-node-lease Active 29m kube-public Active 29m kube-system Active 29m production Active 23m

The production namespace appears at the bottom of the list, so we can continue.

9. In the Cloud Shell, execute the following command to create the resource in the namespace called production:

kubectl apply -f ./production-pod.yaml

This will fail indicating that Username 2 does not have the correct permission to create Pods. Username 2 only has the viewer permissions it started the lab with at this point because you have not bound any other role to that account yet. You will now change that.

10. Switch back to the Username 1 Google Cloud Console tab.

Note: Make sure you are on the Username 1 Google Cloud Console tab.

11. In the Cloud Shell for Username 1, execute the following command to create the RoleBinding that grants Username 2 the pod-reader role that includes the permission to create Pods in the production namespace:

kubectl apply -f username2-editor-binding.yaml

12. In the Cloud Shell for Username 1, execute the following command to look for the new role binding:

kubectl get rolebinding

Output:

No resources found in default namespace.

The rolebinding doesn't appear because kubectl is showing the default namespace.

13. In the Cloud Shell for Username 1, execute the following command with the production namespace specified:

kubectl get rolebinding --namespace production

Output:

NAME AGE username2-editor 23s

14. Switch back to the Username 2 Google Cloud Console tab.

Note: Make sure you are on the Username 2 Google Cloud Console tab.

15. In the Cloud Shell for Username 2, execute the following command to create the resource in the namespace called production:

kubectl apply -f ./production-pod.yaml

This should now succeed as Username 2 now has the Create permission for Pods in the production namespace.

16. Verify the Pod deployed properly in the production namespace by using the following command:

kubectl get pods --namespace production

Output:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 16m production-pod 1/1 Running 0 20s

You should see your newly created Pod.

17. Verify that only the specific RBAC permissions granted by the pod-reader role are in effect for Username 2 by attempting to delete the production-pod:

kubectl delete pod production-pod --namespace production

This fails because Username 2 does not have the delete permission for Pods.

Click Check my progress to verify the objective.

Roles and RoleBindings

End your lab

When you have completed your lab, click End Lab. Google Cloud Skills Boost removes the resources you’ve used and cleans the account for you.

You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.

The number of stars indicates the following:

• 1 star = Very dissatisfied
• 2 stars = Dissatisfied
• 3 stars = Neutral
• 4 stars = Satisfied
• 5 stars = Very satisfied

You can close the dialog box if you don't want to provide feedback.

For feedback, suggestions, or corrections, please use the Support tab.

Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.