Authentication and Authorization on Openshift

There are several OpenShift resources related to authentication and authorization. The following is a list of the primary resource types and their definitions:

• User – In the OpenShift Container Platform architecture, users are entities that interact with the API server. Assign permissions by adding roles to the user directly or to the groups of which the user is a member.
• Identity – The identity resource keeps a record of successful authentication attempts from a specific user and identity provider. Any data concerning the source of the authentication is stored on the identity. Only a single user resource is associated with an identity resource.
• Service Account – In OpenShift, applications can communicate with the API independently when user credentials cannot be acquired. To preserve the integrity of a regular user’s credentials, credentials are
  not shared and service accounts are used instead. Service accounts enable you to control API access without the need to borrow a regular user’s credentials.
• Group – Groups represent a specific set of users. Users are assigned to one or to multiple groups.  OpenShift Container Platform also provides system groups or virtual groups that are provisioned automatically by the cluster.
• Role – A role defines a set of permissions that enables a user to perform API operations over one or more resource types. You grant permissions to users, groups, and service accounts by assigning roles to them.

User and identity resources are usually not created in advance. They are usually created automatically by OpenShift after a successful interactive log in using OAuth.

OpenShift OAuth server can be configured to use many identity providers. The following lists includes the more common ones:

• HTPasswd – Validates user names and passwords against a secret that stores credentials generated using the htpasswd command.
  
• Keystone – Enables shared authentication with an OpenStack Keystone v3 server.
  
• LDAP – Configures the LDAP identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication.
  
• GitHub or GitHub Enterprise – Configures a GitHub identity provider to validate user names and passwords against GitHub or the GitHub Enterprise OAuth authentication server.
  
• OpenID Connect – Integrates with an OpenID Connect identity provider using an Authorization Code Flow.

The OAuth custom resource must be updated with your desired identity provider. You can define multiple identity providers, of the same or different kinds, on the same OAuth custom resource.

 

Authenticating as a Cluster Administrator
Before you can configure an identity provider and manage users, you must access your OpenShift cluster as a cluster administrator. A newly-installed OpenShift cluster provides two ways to authenticate API requests with cluster administrator privileges:
• Use the kubeconfig file, which embeds an X.509 client certificate that never expires.
• Authenticate as the kubeadmin virtual user. Successful authentication grants an OAuth access token.

To create additional users and grant them different access levels, you must configure an identity provider and assign roles to your users.

• Authenticating Using the X.509 Certificate
  The kubeconfig file contains specific details and parameters used by the CLI to connect a client to the correct API server, including an X.509 certificate.
  The installation logs provide the location of the kubeconfig file:
  

To use the kubeconfig file to authenticate oc commands, you must copy the file to your workstation and set the absolute or relative path to the KUBECONFIG environment variable. Then, you can run any oc that requires cluster administrator privileges without logging in to OpenShift.

As an alternative, you can use the --kubeconfig option of the oc command.

• Authenticating Using the kubeadmin Virtual User
  After installation completes, OpenShift creates the kubeadmin virtual user. The kubeadmin secret in the kube-system namespace contains the hashed password for the kubeadmin user. The kubeadmin user has cluster administrator privileges. The OpenShift installer dynamically generates a unique kubeadmin password for the cluster. The installation logs provide the kubeadmin credentials used to log in to the cluster. The cluster
  installation logs also provide log in, password, and the URL for console access.
  

 

Deleting the Virtual User
After you define an identity provider, create a new user, and assign that user the cluster-admin role, you can remove the kubeadmin user credentials to improve cluster security.

If you delete the kubeadmin secret before you configure another user with cluster admin privileges, then the only way you can administer your cluster is using the kubeconfig file. If you do not have a copy of this file in a safe location, then you cannot recover administrative access to your cluster. The only alternative is destroying and reinstalling your cluster.

Configuring the HTPasswd Identity Provider

The HTPasswd identity provider validates users against a secret that contains user names and passwords generated with the htpasswd command from the Apache HTTP Server project. Only a cluster administrator can change the data inside the HTPasswd secret. Regular users cannot change their own passwords. Most production environments require a more
powerful identity provider that integrates with the organization’s identity management system.

 

Configuring the OAuth Custom Resource
To use the HTPasswd identity provider, the OAuth custom resource must be edited to add an entry to the .spec.identityProviders array:

• name: my_htpasswd_provider – This provider name is prefixed to provider user names to form an identity name.
• mappingMethod: claim – Controls how mappings are established between provider identities and user objects.
• name: htpasswd-secret – An existing secret containing data generated using the htpasswd command.

To update the OAuth custom resource, use the oc get command to export the existing OAuth cluster resource to a file in YAML format.

[user@host ~]$ oc get oauth cluster -o yaml > oauth.yaml

Then, open the resulting file in a text editor and make the needed changes to the embedded identity provider settings. After completing modifications and saving the file, you must apply the new custom resource using
the oc replace command.

 

Managing Users with the HTPasswd Identity Provider
Managing user credentials with the HTPasswd Identity Provider requires creating a temporary htpasswd file, making changes to the file, and applying these changes to the secret.

• Creating an HTPasswd File
  The httpd-tools package provides the htpasswd utility, it must be installed and available on your system. Create the htpasswd file.

Use the -c option only when creating a new file. The -c option replaces all file content if the file already exists.

Add or update credentials:

Delete credentials:

• Creating the HTPasswd Secret
  To use the HTPasswd provider, you must create a secret that contains the htpasswd file data. The following example uses a secret named htpasswd-secret.
  
  [user@host ~]$ oc create secret generic htpasswd-secret \ > --from-file htpasswd=/tmp/htpasswd -n openshift-config

  1 2	[user@host ~]$ oc create secret generic htpasswd-secret \ > --from-file htpasswd=/tmp/htpasswd -n openshift-config

• Extracting Secret Data
  When adding or removing users, an administrator cannot assume the validity of a local htpasswd file. Moreover, the administrator might not be on a system that has the htpasswd file. In a real world scenario, it would behoove the administrator to use the oc extract command. By default, the oc extract command saves each key within a configuration map or secret as a
  separate file. Alternatively, all data can then be redirected to a file or displayed as standard output. To extract data from the htpasswd-secret secret to the /tmp/ directory, use the following command. The --confirm option replaces the file if it already exists.

• Updating the HTPasswd Secret
  The secret must be updated after adding, changing, or deleting users. Use the oc set data secret command to update a secret.  The following command updates the htpasswd-secret secret  using the content of the /tmp/htpasswd file.

After updating the secret, the OAuth operator redeploys pods in the openshiftauthentication namespace. Monitor the redeployment of the new OAuth pods by running:

Test additions, changes, or deletions to the secret after the new pods finish deploying.

 

Deleting Users and Identities
When a scenario occurs that requires you to delete a user, it is not sufficient to delete the user from the identity provider. The user and identity resources must also be deleted. You must remove the password from the htpasswd secret, remove the user from the local htpasswd file, and then update the secret.

To delete the user from htpasswd, run the following command:

Update the secret to remove all remnants of the user’s password:

Remove the user resource with the following command:

Identity resources include the name of the identity provider. To delete the identity resource for the manager user, find the resource and then delete it.

 

Assigning Administrative Privileges
The cluster-wide cluster-admin role grants cluster administration privileges to users and groups. This role enables the user to perform any action on any resources within the cluster. The following example assigns the cluster-admin role to the student user.

 

Excercise 1

In this exercise, you will configure the HTPasswd identity provider and create users for cluster administrators.

Add an entry for two htpasswd users, admin and developer. Assign admin a password of redhat and developer a password of developer.

Create an HTPasswd authentication file named htpasswd in the ~/ auth-provider/ directory. Add the admin user with the password of redhat.
Use the htpasswd command to populate the HTPasswd authentication file with the user names and encrypted passwords. The -B option uses bcrypt encryption. By default, the htpasswd command uses the MD5 hashing algorithm when you do not specify other algorithm.

Add the developer user with a password of developer to the ~/auth-provider/htpasswd file. The password for the developer user is stored using MD5, because no hashing algorithm was specified when invoking the htpasswd
command.

Review the contents of the ~/auth-provider/htpasswd file and verify that it includes two entries with hashed passwords: one for the admin user and
another for the developer user.

Log in to the cluster as the kubeadmin user :

Create a secret from the ~/auth-provider/htpasswd file. To
use the HTPasswd identity provider, you must define a secret with a key named htpasswd that contains the HTPasswd user file ~/auth-provider/
htpasswd.

Assign the admin user the cluster-admin role :

Export the existing OAuth resource to a file named oauth.yaml in the ~/auth-provider directory:

Edit the ~/auth-provider/oauth.yaml file with your preferred text editor. You can choose the names of the identityProviders and fileData structures. For this exercise, use the myusers and localusers values respectively. The completed custom resource should match the following. Note that htpasswd,
mappingMethod, name and type are at the same indentation level.

Apply the custom resource defined in the previous step :

Pods in the openshift-authentication namespace will redeploy if the oc
replace command succeeds. Provided the previously created secret was created correctly, you can log in using the HTPasswd identity provider.

Log in to the cluster as the admin user to verify the HTPasswd authentication is configured correctly. The authentication operator takes some time to load the configuration changes from the previous step.

Use the oc get nodes command to verify that the admin user has the clusteradmin role.

Log in to the cluster as the developer user to verify the HTPasswd authentication is configured correctly

Use the oc get nodes command to verify that the developer and admin users
do not share the same level of access.

Log in as the admin user.

List the current users

As the admin user, create a new HTPasswd user named manager with a password of redhat.

Extract the file data from the secret to the ~/auth-provider/htpasswd file.

Add an entry to your ~/auth-provider/htpasswd file for the
additional user manager with a password of redhat.

Review the contents of your ~/auth-provider/htpasswd file and verify that it includes three entries with hashed passwords: one each for the admin,
developer and manager users

You must update the secret after adding additional users. Use the oc set datasecret command to update the secret. If you receive a failure, then rerun the command again after a few moments as the oauth operator might still be reloading

Wait a few moments for the authentication operator to reload, and then log in to the cluster as the manager user.

Create a new project named auth-provider, and then verify that the developer user cannot access the project.
As the manager user, create a new auth-provider project.

Log in as the developer user.

Attempt to delete the auth-provider project.

Change the password for the manager user.
Log in as the admin user.

Extract the file data from the secret to the ~/auth-provider/htpasswd file.

Generate a random user password and assign it to the MANAGER_PASSWD variable

Update the manager user to use the password stored in the MANAGER_PASSWD variable.

Update the secret

Log in as the manager user to verify the updated password.

8. Remove the manager user.
Log in as the admin user

Extract the file data from the secret to the ~/auth-provider/htpasswd file.

Delete the manager user from the ~/auth-provider/htpasswd file.

Update the secret.

Delete the identity resource for the manager user.

Delete the user resource for the manager user.

Now, attempts to log in as the manager user fail.

Verify you have provided correct credentials.
List the current users to verify that the manager user is deleted.

Display the list of current identities to verify that the manager identity is deleted.

Extract the secret and verify that only the users admin and developer are
displayed. Using --to-sends the secret to STDOUT rather than saving it to a file.

9. Remove the identity provider and clean up all users.
Log in as the kubeadmin user.

Delete the auth-provider project.

Edit the resource in place to remove the identity provider from OAauth:

Delete all the lines under spec:, and then append {} after spec:. Leave all the
other information in the file unchanged. Your spec: line should match the following:

Save your changes, and then verify that the oc edit command applied you changes:

Delete the localusers secret from the openshift-config namespace.

Delete all user resources.

Delete all identity resources.

This concludes the guided exercise.

 

Managing Users

• Managing existing users is a three-step procedure
  • Use oc extract to extract the current username and password from the secret and write it back to htpasswd
  • Update the current credentials using htpasswd
  • Use oc set data secret to write the updated data to the secret
• After updating the secret, the OAuth operator redeploys Pods in the openshift-authentication namespace

 

Changing a User Password

• oc extract secret/htpasswd-secret -n openshift-config --to /tmp/ --confirm
• htpasswd -B -b /tmp/htpasswd anna newpassword
• htpasswd -B -b /tmp/htpasswd linda secret
• oc set data secret/htpasswd-secret --from-file htpasswd=/tmp/htpasswd -n openshift-config

 

Deleting Users

• The procedure to delete users is comparable to the procedure to update users
  • Extract the current secret data to a temporary file
  • Use htpasswd -D to delete the user
  • Use oc set data secret to update the secret

 

Working with Groups

• Groups are used to assign additional privileges to people users
• Use oc adm groups to work with Groups
  • oc adm groups new developers
  • oc adm groups add-users developers anna
  • oc get groups will show currently existing groups
• After creating groups, use oc policy to grant privileges (further explained in Lesson 6)
  • oc policy add-role-to-group edit developers

 

 

Assign Administrative Privileges

• To assign Administrative privileges, the user must be added to the cluster-admin role:
  • oc adm policy add-cluster-role-to-user cluster-admin anna
• Tip: Use Tab completion to complete the oc adm policy command

 

Lab: Managing Users

• Use the HTPasswd provider to create users lisa and lori. Both have the passwords set to “password“. User lisa should be granted administrator privileges and user lori should not.
• After creating the users, log in as either of these users to verify that the administrator command oc get nodes works
• After trying this, use oc get users to verify the existence of both users

Edit the oauth.yaml file:

Lori is oridnary user so she can not get users, lori and admin can do that.

 

 

Role-based Access Control (RBAC)

Role-based access control (RBAC) is a technique for managing access to resources in a computer system. RBAC determines if a user can perform certain actions within the cluster or project. There are two types of roles that can be used depending on the user’s level of responsibility: cluster and local.

Understanding RBAC

• The purpose of RBAC is to connect users to specific roles
• Roles have either a project or a cluster scope
• Different types of users are available
• Users are created as a specific user type, and are granted access to cluster resources using role bindings

The authorization process is managed by rules, roles, and bindings.

• Rule – Allowed actions for objects or groups of objects.
• Role – Sets of rules. Users and groups can be associated with multiple roles.
• Binding – Assignment of users or groups to a role.Red Hat OpenShift Container Platform (RHOCP) defines two groups of roles and bindings depending on the user’s scope and responsibility: cluster roles and local roles.
• Cluster Role – Users or groups with this role level can manage the OpenShift cluster.
• Local Role – Users or groups with this role level can only manage elements at a
  project level.

Understanding Roles

• A role is an API resource that gives specific users access to OpenShift resources, based on verbs
  • Verbs are used as permissions, and include get, list, watch, create, update, patch, delete
• Cluster Roles are created when OpenShift is installed
• Local Roles provide access to project-based resources
• Use oc describe clusterrole.rbac for an overview of currently existing cluster roles

Understanding Role Bindings

• A Role Binding is used to connect a cluster role to a user or group
• Use oc describe clusterrolebinding.rbac for an overview of bindings between users/groups and roles
• Use oc describe rolebindings.rbac to see all roles with a non-cluster scope
• Use oc describe rolebindings.rbac -n myproject to see local roles assigned to a specific project

Understanding Default Roles

• Some default roles are provided to be applied locally or to the entire cluster
  • admin: gives full control to all project resources
  • basic-user: gives read access to projects
  • cluster-admin: allows a user to perform any action in the cluster
  • cluster-status: allows a user to request status information
  • edit: allows creating and modifying common application resources, but gives no access to permissions, quotas, or limit ranges
  • self-provisioner: this cluster role allows users to create new projects
  • view: allows users to view but not modify project resources
• The admin role gives users full project permissions
• The edit role corresponds to the typical developer user

The admin role gives a user access to project resources such as quotas and limit ranges, and also the ability to create new applications. The edit role gives a user sufficient access to act as a developer inside the project, but working under the constraints configured by a project administrator.

Understanding User Types

• Regular users represent a user object that is granted access to the cluster  platform
• System users are created automatically to allow system components to access specific resources
  • system:admin has full admin access
  • system:openshift-registry is used for registry access
  • system:node:serverl.example.com is used for node access
• Service accounts are special system accounts used to give extra privileges to pods or deployments
  • deployer: is used to create deployments
  • builder: is used to create build configs in S2I

Managing RBAC

• Cluster administrators can use oc adm policy to manage cluster and namespace roles
  • oc adm policy add-cluster-role-to-user rolenname username
  • oc adm policy remove-cluster-role-from-user rolename username
• To figure out who can do what, use oc adm policy who-can delete user

Managing RBAC Using the CLI

• Cluster administrators can use the oc adm policy command to both add and remove cluster roles and namespace roles.
  To add a cluster role to a user, use the add-cluster-role-to-user subcommand:

For example, to change a regular user to a cluster administrator, use the following command:

To remove a cluster role from a user, use the remove-cluster-role-from-user
subcommand:

For example, to change a cluster administrator to a regular user, use the following command:

Rules are defined by an action and a resource. For example, the create user rule is part of the cluster-admin role. You can use the oc adm policy who-can command to determine if a user can execute an action on a resource. For example:

• Project administrators can use the oc policy command to add and remove namespace roles. Add a specified role to a user with the add-role-to-user subcommand. For example:
  
  [user@host ~]$ oc policy add-role-to-user role-name username -n project

  1	[user@host ~]$ oc policy add-role-to-user role-name username -n project

  
  For example, to add the user dev to the role basic-user in the wordpress project:

 

 

Exercise 1

 

Excercise 2

List all cluster role bindings that reference the self-provisioner cluster role.

Confirm that the self-provisioners cluster role binding that you found
in the previous step assigns the self-provisioner cluster role to the
system:authenticated:oauth group.

Remove the self-provisioner cluster role from the system:authenticated:oauth virtual group, which deletes the selfprovisioners role binding.

You can safely ignore the warning about your changes being lost. Verify that the role has been removed from the group. The cluster role binding selfprovisioners should not exist.

Determine if any other cluster role bindings reference the self-provisioner
cluster role:

Log in as the leader user with a password of redhat

Try to create a project, the operation should fail.

Log in as the admin user.

Create the auth-rbac project.

Grant project administration privileges to the leader user on the auth-rbac
project.

Create a group called dev-group.

Add the developer user to dev-group.

Create a second group called qa-group.

Add the qa-engineer user to qa-group.

Review all existing OpenShift groups to verify that they have the correct members.

Log in as the leader user

Add write privileges to dev-group on the auth-rbac project.

Add read privileges to qa-group on the auth-rbac project.

Review all role bindings on the auth-rbac project to verify that they assign roles to the correct groups and users. The following output omits default role bindings assigned by OpenShift to service accounts.

Log in as the developer user

Deploy an Apache HTTP Server using the standard image stream from OpenShift.

Try to grant write privileges to the qa-engineer user, the operation should fail

Verify that the qa-engineer user only has read privileges on the httpd application.

Attempt to scale the httpd application, the operation should fail.

Log in as the admin user

Restore project creation privileges for all users by recreating the selfprovisioners cluster role binding created by the OpenShift installer

You can safely ignore the warning that the group was not found.

 

Excercise.

We have ~/auth-review/tmp_users file:

1. Update the existing ~/auth-review/tmp_users HTPasswd authentication
file to remove the analyst user. Ensure that the tester and leader users in the file use a password of Labreview. Add two new entries to the file for the users admin and developer. Use Labreview as the password for each new user.
2. Log in to your OpenShift cluster as the kubeadmin user using the
password  defined in the /root/.kube/config file as the password. Configure your cluster to use the HTPasswd identity provider using the user names and passwords in the ~/auth-review/tmp_users file.
3. Make the admin user a cluster administrator. Log in as both admin and as developer to verify HTPasswd user configuration and cluster privileges.
4. As the admin user, remove the ability to create projects cluster wide.
5. Create a group named managers, and add the leader user to the group. Grant project creation privileges to the managers group. As the leader user, create the auth-review project.
6. Create a group named developers and grant edit privileges on the auth-review project. Add the developer user to the group.
7. Create a group named qa and grant view privileges on the auth-review project. Add the tester user to the group.

 

1. Remove the analyst user from the ~/auth-review/tmp_users
HTPasswd authentication file.

Update the entries for the tester and leader users so that they use a password of Labreview. Add entries for the admin and developer users using a password of Labreview.

Review the contents of the ~/auth-review/tmp_users file. It does not contain a line for the analyst user. It includes two new entries with hashed
passwords for the admin and developer users.

 

2. Log in to the cluster as the kubeadmin user.

Create a secret named auth-review using the ~/auth-review/tmp_users file

Export the existing OAuth resource to ~/auth-review/oauth.yaml.

Edit the ~/auth-review/oauth.yaml file to replace the spec: {} line with the following bold lines. Note that htpasswd, mappingMethod, name and type are at the same indentation level.

Apply the customized resource defined in the previous step

A successful update to the oauth/cluster resource recreates the oauthopenshift pods in the openshift-authentication namespace.

Wait until the new oauth-openshift pods are ready and running and the previous pods have terminated.

Press Ctrl+C to exit the watch command.

3. Assign the admin user the cluster-admin role

Log in to the cluster as the admin user to verify that HTPasswd authentication was configured correctly.

Use oc get nodes command to verify the admin user has the cluster-admin role. The names of the nodes from your cluster might be different.

Log in to the cluster as the developer user to verify the HTPasswd authentication is configured correctly.

Use the oc get nodes command to verify that the developer user does not have cluster administration privileges.

4. Log in to the cluster as the admin user.

Remove the self-provisioner cluster role from the system:authenticated:oauth virtual group.

5. Create a group named managers.

Add the leader user to the managers group.

Assign the self-provisioner cluster role to the managers group

As the leader user, create the auth-review project.

The user who creates a project is automatically assigned the admin role on the project.

6. Log in to the cluster as the admin user.

Create a group named developers.

Add the developer user to the developers group

Grant edit privileges to the developers group on the auth-review project

7. Create a group named qa.

Add the tester user to the qa group.

Grant view privileges to the qa group on the auth-review project.

 

Excercise

 

 

Creating Roles

• New roles can be created by assigning verbs and resources to the newly created role
• oc create role podview --verb-get --resource-pod -n userstuff
• oc adm policy add-role-to-user podview ahmed --role-namespace=userstuff -n userstuff • oc create clusterrole podviewonly --verb-get --resource=pod
• oc adm policy add-cluster-role-to-user podviewonly lori