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 log aggregation lab we saw that there was an error in reference to a Service Account.

As OpenShift is a declarative platform, some actions will be performed by the platform and not by the end user (when he or she issues 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 the one taking the responsibility of running the pods, and OpenShift uses and injects this service account into every pod that is launched. By changing the permissions for that service account, we can do interesting things.

You can view current permissions in the web console: go to Workloads → Topology, click the parksmap entry, open the Details tab in the side panel, and then click the Namespace link.

Namespace

Then select the RoleBindings tab to see all the permissions defined for the selected project.

Membership

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 the Project. You’ll soon learn why!

The parksmap application runs as a Service Account in our project on the cluster: namely the default Service Account. It is to this Service Account that we can grant the necessary view access that will allow it to query the API to see what resources are within the Project. This also has the added benefit of addressing the cause of the error message we witnessed previously in the logs.

Choose an approach represented by the following tabs to update the default Service Account in the %PROJECT% project

  • OpenShift Console

  • oc Command Line

  1. From the %PROJECT% project page, open the RoleBindings tab and click the Create binding button.

    Service account list

  2. Fill in the form: view as the Name, view as the Role name, ServiceAccount as the Subject, %PROJECT% as the Subject namespace, and default as the Subject name. The Namespace field is already set to %PROJECT% from the project selector.

    Service account edit

  3. Once you’re finished editing permissions, click on the Create button. You should then be able to see it on the RoleBindings list for the %PROJECT% project.

    Service account changed 
oc project %PROJECT%

Then use the oc policy add-role-to-user command to give the predefined view role to the user:

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:%PROJECT%: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

oc rollout restart deployment/parksmap

A new deployment is immediately started. Return to Workloads → Topology and click the parksmap entry again to watch it happen. You might not be fast enough! But it will be reflected in the ReplicaSet number.

Application deployed

If you look at the logs for the application now, you should see no errors. That’s great.