Permissions

Almost every interaction with an OpenShift environment that you can think of requires going through the OpenShift’s control plane API. All API interactions are both authenticated (AuthN - who are you?) and authorized (AuthZ - are you allowed to do what you are asking?).

In the logging section, you saw an error related to a Service Account.

As OpenShift is a declarative platform, some actions will be performed by the platform and not by the end user issuing a command. These actions are performed using a Service Account which is a special type of user that the platform will use internally.

OpenShift automatically creates a few special service accounts in every project. The default service account is responsible for running the Pods, and OpenShift automatically injects this service account into every Pod that is launched. By changing the permissions for that service account, you can enable additional functionality.

To view current permissions in the web console, go to the Topology view, click the parksmap entry, go to the Details tab, and then click the Namespace.

Select the Role Bindings tab and filter by Namespace Role Binding to see all permissions for the selected project.

Exercise: Grant Service Account View Permissions

The parksmap application wants to talk to the OpenShift API to learn about other Pods, Services, and resources within your Project. You’ll soon learn why!

The parksmap application runs as a Service Account in your project on the cluster: namely the default Service Account. You can grant the necessary view access to this Service Account to allow it to query the API and see what resources are within the Project. This addresses the cause of the error message you saw previously in the logs.

Choose one of the options below - either OpenShift Console or oc command line — to update the default Service Account in the wksp-userX project:

OPTION A: OpenShift Console:

Go to Home → Projects → wksp-userX, then Role Bindings and then click the Create Binding button.
Configure the following fields: Role Binding Name: view, Namespace: wksp-userX, Role Name: view, Subject: Service Account, Subject Namespace: wksp-userX, Subject Name: default.
Once you’re finished editing permissions, click on the Create button. You should then be able to see the new view item in the RoleBindings list for the wksp-userX project.

OPTION B: oc command line:

First, confirm you’re in the right project context:

oc project wksp-userX

Then use the oc policy add-role-to-user command to grant the predefined view role to the service account:

oc policy add-role-to-user view -z default

What does the -z flag do?

From the -h output on oc policy:

-z, --serviceaccount=[]: service account in the current namespace to use as a user

The -z syntax is a special one that saves us from having to type out the entire string, which, in this case, is system:serviceaccount:wksp-userX:default. It’s a nifty shortcut.

The -z flag will only work for service accounts in the current project. If you’re referring to a service account in a different project, use the -n <project> switch.

Exercise: Redeploy Application

Use the oc rollout command to restart the parksmap application. This will create a new Pod.

oc rollout restart deployment/parksmap

A new deployment is immediately started. Return to Topology view and click the parksmap entry again to watch it happen. The deployment happens quickly, but you can see the change reflected in the ReplicaSet number. You can also use the oc get pods command to see that the new Pod has an age that’s just a few seconds old.

If you check the application logs you should see no errors.