Bookmark this page

Chapter 3. Authentication and Authorization

Abstract

Goal	Configure authentication with the HTPasswd identity provider and assign roles to users and groups.
Objectives	Configure the HTPasswd identity provider for OpenShift authentication. Define role-based access controls and apply permissions to users.
Sections	Configure Identity Providers (and Guided Exercise) Define and Apply Permissions with RBAC (and Guided Exercise)
Lab	Authentication and Authorization

Configure Identity Providers

Objectives

Configure the HTPasswd identity provider for OpenShift authentication.

OpenShift Users and Groups

Several OpenShift resources relate to authentication and authorization. The following list shows the primary resource types and their definitions:

User: In the OpenShift Container Platform architecture, users are entities that interact with the API server. The user resource represents an actor within the system. Assign permissions by adding roles to the user directly or to the groups that the user is a member of.
Identity: The identity resource keeps a record of successful authentication attempts from a specific user and identity provider. Any data about the source of the authentication is stored on the identity.
Service Account: In OpenShift, applications can communicate with the API independently when user credentials cannot be acquired. To preserve the integrity of the credentials for a regular user, credentials are not shared and service accounts are used instead. With service accounts, you can 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 groups. Authorization policies use groups to assign permissions to multiple users at the same time. For example, to grant 20 users access to objects within a project, it is better to use a group instead of granting access to each user individually. OpenShift Container Platform also provides system groups or virtual groups that are provisioned automatically by the cluster.
Role: A role defines the API operations that a user has permissions to perform on specified 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. OpenShift usually creates these resources automatically after a successful interactive login with OAuth.

Authenticating API Requests

The authentication and authorization security layers enable user interaction with the cluster. When a user makes a request to the API, the API associates the user with the request. The authentication layer authenticates the user. On successful authentication, the authorization layer either accepts or rejects the API request. The authorization layer uses role-based access control (RBAC) policies to determine user privileges.

The OpenShift API has two methods for authenticating requests:

OAuth access tokens
X.509 client certificates

If the request does not present an access token or certificate, then the authentication layer assigns it the system:anonymous virtual user and the system:unauthenticated virtual group.

The Authentication Operator

The OpenShift Container Platform provides the Authentication operator, which runs an OAuth server. The OAuth server provides OAuth access tokens to users when they attempt to authenticate to the API. An identity provider must be configured and available to the OAuth server. The OAuth server uses an identity provider to validate the identity of the requester. The server reconciles the user with the identity and creates the OAuth access token for the user. OpenShift automatically creates identity and user resources after a successful login.

Identity Providers

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

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

The OAuth custom resource must be updated with your chosen 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. One way is to use the kubeconfig file, which embeds an X.509 client certificate that never expires. Another way is to 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 with the X.509 Certificate

During installation, the OpenShift installer creates a unique kubeconfig file in the auth directory. The kubeconfig file contains specific details and parameters for 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:

INFO Run 'export KUBECONFIG=root/auth/kubeconfig' to manage the cluster with 'oc'.

Note

In the classroom environment, the utility machine stores the kubeconfig file at /home/lab/ocp4/auth/kubeconfig.

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 command that requires cluster administrator privileges without logging in to OpenShift.

[user@host ~]$ export KUBECONFIG=/home/user/auth/kubeconfig
[user@host ~]$ oc get nodes

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

[user@host ~]$ oc --kubeconfig /home/user/auth/kubeconfig get nodes

Authenticating with 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 to log in to the cluster. The cluster installation logs also provide the login, password, and the URL for console access.

...output omitted...
INFO The cluster is ready when 'oc login -u kubeadmin -p shdU_trbi_6ucX_edbu_aqop'
...output omitted...
INFO Access the OpenShift web-console here:
     https://console-openshift-console.apps.ocp4.example.com
INFO Login to the console with user: kubeadmin, password: shdU_trbi_6ucX_edbu_aqop

Note

In the classroom environment, the utility machine stores the password for the kubeadmin user in the /home/lab/ocp4/auth/kubeadmin-password file.

Deleting the Virtual User

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

[user@host ~]$ oc delete secret kubeadmin -n kube-system

Warning

If you delete the kubeadmin secret before you configure another user with cluster admin privileges, then you can administer your cluster only by 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 to destroy and reinstall your cluster.

Warning

Do not delete the kubeadmin user at any time during this course. The kubeadmin user is essential to the course lab architecture. If you deleted this user, you would have to delete the lab environment and re-create it.

Configuring the HTPasswd Identity Provider

The HTPasswd identity provider validates users against a secret that contains usernames and passwords that are 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.

Managing users with the HTPasswd identity provider might suffice for a proof-of-concept environment with a small set of users. However, 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:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_htpasswd_provider 
    mappingMethod: claim 
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpasswd-secret

	This provider name is prefixed to provider user names to form an identity name.
	Controls how mappings are established between provider identities and user objects. With the default `claim` value, you cannot log in with different identity providers.
	An existing secret that contains data that is generated by using the `htpasswd` command.

Updating the OAuth Custom Resource

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 by using the oc replace command.

[user@host ~]$ oc replace -f oauth.yaml

Managing Users with the HTPasswd Identity Provider

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

Creating an HTPasswd File

The httpd-tools package provides the htpasswd utility, which must be installed and available on your system.

Create the htpasswd file.

[user@host ~]$ htpasswd -c -B -b /tmp/htpasswd student redhat123

Important

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

Add or update credentials.

[user@host ~]$ htpasswd -b /tmp/htpasswd student redhat1234

Delete credentials.

[user@host ~]$ htpasswd -D /tmp/htpasswd student

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

Important

A secret that the HTPasswd identity provider uses requires adding the htpasswd= prefix before specifying the path to the file.

Extracting Secret Data

When adding or removing users, use the oc extract command to retrieve the secret. Extracting the secret ensures that you work on the current set of users.

By default, the oc extract command saves each key within a configuration map or secret as a separate file. Alternatively, you can then redirect all data to a file or display it 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 exists.

[user@host ~]$ oc extract secret/htpasswd-secret -n openshift-config \
  --to /tmp/ --confirm
/tmp/htpasswd

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. Unless the file name is htpasswd, you must specify htpasswd= to update the htpasswd key within the secret.

The following command updates the htpasswd-secret secret in the openshift-config namespace by using the content of the /tmp/htpasswd file.

[user@host ~]$ oc set data secret/htpasswd-secret \
  --from-file htpasswd=/tmp/htpasswd -n openshift-config

After updating the secret, the OAuth operator redeploys pods in the openshift-authentication namespace. Monitor the redeployment of the new OAuth pods by running the following command:

[user@host ~]$ watch oc get pods -n openshift-authentication

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:

[user@host ~]$ htpasswd -D /tmp/htpasswd manager

Update the secret to remove all remnants of the user's password.

[user@host ~]$ oc set data secret/htpasswd-secret \
  --from-file htpasswd=/tmp/htpasswd -n openshift-config

Remove the user resource with the following command:

[user@host ~]$ oc delete user manager
user.user.openshift.io "manager" deleted

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.

[user@host ~]$ oc get identities | grep manager
my_htpasswd_provider:manager   my_htpasswd_provider   manager       manager   ...

[user@host ~]$ oc delete identity my_htpasswd_provider:manager
identity.user.openshift.io "my_htpasswd_provider:manager" deleted

Assigning Administrative Privileges

The cluster-wide cluster-admin role grants cluster administration privileges to users and groups. With this role, the user can perform any action on any resources within the cluster. The following example assigns the cluster-admin role to the student user.

[user@host ~]$ oc adm policy add-cluster-role-to-user cluster-admin student

References

For more information about identity providers, refer to the Understanding Identity Provider Configuration chapter in the Red Hat OpenShift Container Platform 4.14 Authentication and Authorization documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/authentication_and_authorization/index#understanding-identity-provider

Discuss Red Hat OpenShift Administration II: Configuring a Production Cluster

Go to community

Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280)

Haley_Ruccio

26 lip 2023

Configure, manage, and troubleshoot OpenShift clusters and containerized applicationsRed Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280) prepares OpenShift Cluster Administrators to perform daily administration tasks on clusters that host applications provided by internal teams and external vendors, enable self-service for cluster users with different roles, and deploy applications that require special permissions such as such as CI/CD tooling, performance monitoring, and security scanners. This course focuses on configuring multi-tenancy and security features of OpenShift as well as managing OpenShift add-ons based on operators.The skills you learn in this course can be applied using all versions of OpenShift, including Red Hat OpenShift on AWS (ROSA), Azure Red Hat OpenShift, and OpenShift Container Platform.This course is based on OpenShift Container Platform 4.12.5-10 Course TopicsDeploying packaged applications using manifests, templates, kustomize, and helm.Configuring authentication and authorization for users and applications.Protecting network traffic with network policies and exposing applications with proper network access.Deploying and managing applications using resources manifests.Enabling developer self-service of application projects.Managing OpenShift cluster updates and Kubernetes operator updates.Target AudienceSystem Administrators and Platform Operators interested in the ongoing management of OpenShift clusters, applications, users, and add-ons.Site Reliability Engineers interested in the ongoing maintenance and troubleshooting of Kubernetes clusters.System and Software Architects interested in understanding the security of an OpenShift cluster.Recommended TrainingTake our free assessment to gauge whether this offering is the best fit for your skills.Prerequisite: Red Hat OpenShift I: Containers & Kubernetes (DO180 v4.12), or equivalent skills deploying and managing Kubernetes applications using the OpenShift web console and command-line interfaces.Technology considerationsThis course requires internet access to access the cloud-based classroom environment that provides an OpenShift cluster and a remote administrator’s workstation.

476

About pod security standards and warnings

alexcorcoles

17 kwi 2023

(This material has been created with the inputs of instructors and other people. We are trying to get this material published as soon as possible to address some concerns with DO180 and DO280.)With the default configuration, any namespace that you create on OpenShift 4.12 has the following labels: pod-security.kubernetes.io/audit: restrictedpod-security.kubernetes.io/audit-version: v1.24pod-security.kubernetes.io/warn: restrictedpod-security.kubernetes.io/warn-version: v1.24 These labels activate auditing and warning of the restricted pod security standard. The Kubernetes documentation describes the restricted pod security standard. Pod security standards such as restricted are not directly related to security context constraints such as the restricted SCC.Kubernetes uses an admission controller to reject pods that do not comply with pod security standards. An admission controller is a Kubernetes component that inspects every Kubernetes resource before its creation, and acts before Kubernetes creates the resource. This action can include rejecting the creation of the resource, or modifying the resource.The pod security standards are policies that include properties that workloads must follow. For example, the restricted standard requires that containers set the securityContext.allowPrivilegeEscalation field to false.Pod security standards apply both to workloads, such as deployments and jobs, and to pods.When a pod is created, the admission controller inspects the container specifications and enumerates the fields that violate the pod security standard of the namespace. The admission controller inspects the pod-security labels in the namespace to decide which pod security standard to apply (restricted, baseline, or privileged), and which action to take on violations. Namespaces can audit, warn, or enforce pod security standard violations. When the pod-security.kubernetes.io/audit annotation is set to restricted, the admission controller prevents the creation of pods that violate the security standard. When the pod-security.kubernetes.io/audit and pod-security.kubernetes.io/warn annotations are defined in the project, the admission controller does not block the creation of pods, but registers audit events or warnings.The admission controller does not enforce pod security standards for workloads. If the namespace is configured to enforce a pod security standard, then you can create a violating workload. The admission controller enforces only pod security policies on pods.Cluster administrators can use pod security standards to ensure that pods and workloads in namespaces limit their privileges. By limiting privileges, cluster administrators can mitigate what malicious pods can do.The default configuration of user namespaces in OpenShift does not restrict any workload; it only notifies users when they create workloads that do not follow pod security standards that might be enforced in future OpenShift versions.Security Context ConstraintsOpenShift introduced security context constraints (SCC) before the introduction of pod security standards in Kubernetes. SCCs automatically make security modifications to pods when they are created. By default, the system:openshift:scc:restricted-v2 cluster role binding applies to all authenticated users, so regular user workloads use the restricted-v2 SCC. For example, when you execute the following command to create a workload without any security configuration, the SCC adds security configuration to the pods: [user@host ~]$ oc create deployment test --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx (You can add the --dry-run=client -o yaml options to view the deployment manifest. The deployment manifest does not contain the security properties, which are described later.)If you inspect the pods that the deployment created, the SCC makes the following changes: [user@host ~]$ oc get pod test-b8d5658b6-7bxfs -o yamlapiVersion: v1kind: Podmetadata: annotations:... output omitted... openshift.io/scc: restricted-v2 seccomp.security.alpha.kubernetes.io/pod: runtime/default...output omitted...spec: containers: - image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx imagePullPolicy: Always name: hello-world-nginx resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true runAsUser: 1000690000... output omitted... securityContext: fsGroup: 1000690000 seLinuxOptions: level: s0:c26,c20 seccompProfile: type: RuntimeDefault... output omitted... These restrictions satisfy the restricted pod security policy.The result of these defaults means that when creating a workload (such as a deployment) in a namespace without any customization, the restricted pod security standard applies, but the admission controller only warns and audits. If the workload does not satisfy the pod security standard, then the admission controller allows the workload to be created, but prints a message such as the following warning: Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "example" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "database" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "example" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") However, by default Kubernetes creates the deployment pods with the restricted-v2 SCC, with the restrictions that the previous warning included. Due to the following factors, workloads generate only a warning, and the pod security standard admission controller allows their pods:The pod security standard admission controller never enforces pod security standards on workloads (only on pods).By default, namespaces do not enforce pod security standards on pods.By default, regular workloads create pods by using the restricted-v2 SCC, which satisfies the restricted pod security standard.Even if future versions of OpenShift change the default namespace configuration to enforce the restricted pod security standard, users will continue to be able to create workloads without explicitly declaring the restrictions that the pod security standard requires, because the restricted-v2 SCC will apply such restrictions automatically.You can take the following approaches to handling pod security:For most workloads, the restricted-v2 SCC limits pod privileges adequately. When creating a workload, you receive the warning, but the workload creates pods and works correctly.You can also create your workloads by providing a full specification of the security constraints to apply, without relying on the SCC to provide the configuration. By following this approach, privileges are more explicit, and you have greater control, so you can adjust more precisely the specific privileges that are granted to workloads.When the restricted-v2 SCC and the default restricted pod security standard are not adequate for your workload, because either you require further privileges, or you need further restrictions, you must use an existing SCC, or create a custom SCC, and provide explicit security specifications. You can also adjust the namespace labels to choose a different pod security standard, and decide to audit, log, or enforce the standard.

1473

Welcome to the Red Hat OpenShift Administration II (DO280) group in the Red Hat Learning Community!

Deanna

17 kwi 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster!To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO280.Read more about Red Hat OpenShift Administration II here.Thanks!

1334

Revision: do280-4.14-08d11e1

Red Hat OpenShift Administration II: Configuring a Production Cluster

Chapter 3. Authentication and Authorization

Configure Identity Providers

Objectives

OpenShift Users and Groups

Authenticating API Requests

The Authentication Operator

Identity Providers

Authenticating as a Cluster Administrator

Authenticating with the X.509 Certificate

Note

Authenticating with the kubeadmin Virtual User

Note

Deleting the Virtual User

Warning

Warning

Configuring the HTPasswd Identity Provider

Configuring the OAuth Custom Resource

Updating the OAuth Custom Resource

Managing Users with the HTPasswd Identity Provider

Creating an HTPasswd File

Important

Creating the HTPasswd Secret

Important

Extracting Secret Data

Updating the HTPasswd Secret

Deleting Users and Identities

Assigning Administrative Privileges

References

Authenticating with the `kubeadmin` Virtual User