DO280 - ch03s02

Bookmark this page

Guided Exercise: Configure Identity Providers

Configure the HTPasswd identity provider and create users for cluster administrators.

Outcomes

Create users and passwords for HTPasswd authentication.
Configure the Identity Provider for HTPasswd authentication.
Assign cluster administration rights to users.

[student@workstation ~]$ lab start auth-providers

The command ensures that the cluster API is reachable, the httpd-utils package is installed, and that the authentication settings are configured to the installation defaults.

Instructions

Add an entry for two users, new_admin and new_developer. Assign the new_admin user the redhat password, and assign the new_developer user the developer password.
1. Create an HTPasswd authentication file named htpasswd in the ~/DO280/labs/auth-providers/ directory. Add the new_admin user with the redhat password. The file name is arbitrary; this exercise uses the ~/DO280/labs/auth-providers/htpasswd file.
  Use the htpasswd command to populate the HTPasswd authentication file with the usernames and encrypted passwords. The -B option uses bcrypt encryption. By default, the htpasswd command uses the MD5 hashing algorithm if you do not specify another algorithm.
```
[student@workstation ~]$ htpasswd -c -B -b ~/DO280/labs/auth-providers/htpasswd \
    new_admin redhat
Adding password for user new_admin
```
2. Add the new_developer user with the developer password to the ~/DO280/labs/auth-providers/htpasswd file. The password for the new_developer user is hashed with the MD5 algorithm, because no algorithm was specified and MD5 is the default hashing algorithm.
```
[student@workstation ~]$ htpasswd -b ~/DO280/labs/auth-providers/htpasswd \
    new_developer developer
Adding password for user new_developer
```
3. Review the contents of the ~/DO280/labs/auth-providers/htpasswd file and verify that it includes two entries with hashed passwords: one for the new_admin user and another for the new_developer user.
```
[student@workstation ~]$ cat ~/DO280/labs/auth-providers/htpasswd
new_admin:$2y$05$qQaFbpx4hbf4uZe.SMLSduTN8uN4DNJMJ4jE5zXDA57WrTRlpu2QS
new_developer:$apr1$S0TxtLXl$QSRfBIufYP39pKNsIg/nD1
```

[student@workstation ~]$ oc login -u admin -p redhatocp \
    https://api.ocp4.example.com:6443
Login successful.

...output omitted...

Create a secret from the ~/DO280/labs/auth-providers/htpasswd file. To use the HTPasswd identity provider, you must define a secret with a key named htpasswd that contains the HTPasswd user file ~/DO280/labs/auth-providers/htpasswd.
```
[student@workstation ~]$ oc create secret generic localusers \
    --from-file htpasswd=~/DO280/labs/auth-providers/htpasswd \
    -n openshift-config
secret/localusers created
```

Assign the new_admin user the cluster-admin role.

[student@workstation ~]$ oc adm policy add-cluster-role-to-user \
    cluster-admin new_admin
Warning: User 'new_admin' not found
clusterrole.rbac.authorization.k8s.io/cluster-admin added: "new_admin"

Note

The output indicates that the new_admin user is not found. You can safely ignore this warning.

Update the HTPasswd identity provider for the cluster so that your users can authenticate. Configure the custom resource file and update the cluster.
1. Export the existing OAuth resource to a file named oauth.yaml in the ~/DO280/labs/auth-providers directory.
```
[student@workstation ~]$ oc get oauth cluster \
    -o yaml > ~/DO280/labs/auth-providers/oauth.yaml
```
  Note
  For convenience, an oauth.yaml file that contains the completed custom resource file is downloaded to ~/DO280/solutions/auth-providers.
2. Edit the ~/DO280/labs/auth-providers/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 structure. Ensure that the htpasswd, mappingMethod, name, and type strings are at the same indentation level.
```
apiVersion: config.openshift.io/v1
kind: OAuth
...output omitted...
spec:
  identityProviders:
  - ldap:
...output omitted...
    type: LDAP
  - htpasswd:
      fileData:
        name: localusers
    mappingMethod: claim
    name: myusers
    type: HTPasswd
```
3. Apply the custom resource that was defined in the previous step.
```
[student@workstation ~]$ oc replace -f ~/DO280/labs/auth-providers/oauth.yaml
oauth.config.openshift.io/cluster replaced
```
  Note
  Authentication changes require redeploying pods in the openshift-authentication namespace.
  Use the watch command to examine the status of workloads in the openshift-authentication namespace.
```
[student@workstation ~]$ watch oc get all -n openshift-authentication
NAME                                   READY   STATUS    RESTARTS   AGE
pod/oauth-openshift-6d68ffb9dc-6f8dr   1/1     Running   3          2m
...output omitted...
```
  A few minutes after you ran the oc replace command, the redeployment starts. Wait until new pods are running. Press Ctrl+C to exit the watch command.
  Provided that the previously created secret was created correctly, you can log in by using the HTPasswd identity provider.

Log in to the cluster as the new_admin user to verify that the HTPasswd authentication is configured correctly. The authentication operator takes some time to load the configuration changes from the previous step.
Note
If the authentication fails, then wait a few moments and try again.
```
[student@workstation ~]$ oc login -u new_admin -p redhat
Login successful.

...output omitted...
```

Use the oc get nodes command to verify that the new_admin user has the cluster-admin role.

[student@workstation ~]$ oc get nodes
NAME       STATUS   ROLES           		 AGE  VERSION
master01   Ready    control-plane,master,worker  13d  v1.27.6+f67aeb3

Log in to the cluster as the new_developer user to verify that the HTPasswd authentication is configured correctly.
```
[student@workstation ~]$ oc login -u new_developer -p developer
Login successful.

...output omitted...
```

Use the oc get nodes command to verify that the new_developer and new_admin users do not have the same level of access.

[student@workstation ~]$ oc get nodes
Error from server (Forbidden): nodes is forbidden: User "new_developer" cannot list resource "nodes" in API group "" at the cluster scope

[student@workstation ~]$ oc login -u new_admin -p redhat
Login successful.

...output omitted...

List the current users.

[student@workstation ~]$ oc get users
NAME            UID                                   ...  IDENTITIES
admin           6126c5a9-4d18-4cdf-95f7-b16c3d3e7f24  ...  ...
new_admin       489c7402-d318-4805-b91d-44d786a92fc1  ...  myusers:new_admin
new_developer   8dbae772-1dd4-4242-b2b4-955b005d9022  ...  myusers:new_developer

Note

You might see additional users from previously completed exercises.

Display the list of current identities.

[student@workstation ~]$ oc get identity
NAME                   IDP NAME   IDP USER NAME  USER NAME
                                            USER UID
...                    ...        ...            admin
                                            6126c5a9-4d18-4cdf-95f7-b16c3d3e7f24
myusers:new_admin      myusers    new_admin      new_admin
                                            489c7402-d318-4805-b91d-44d786a92fc1
myusers:new_developer  myusers    new_developer  new_developer
                                            8dbae772-1dd4-4242-b2b4-955b005d9022

Note

You might see additional identities from previously completed exercises.

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

Extract the file data from the secret to the ~/DO280/labs/auth-providers/htpasswd file.

[student@workstation ~]$ oc extract secret/localusers -n openshift-config \
    --to ~/DO280/labs/auth-providers/ --confirm
/home/student/DO280/labs/auth-providers/htpasswd

Add an entry to your ~/DO280/labs/auth-providers/htpasswd file for the additional manager user with the redhat password.

[student@workstation ~]$ htpasswd -b ~/DO280/labs/auth-providers/htpasswd \
    manager redhat
Adding password for user manager

Review the contents of your ~/DO280/labs/auth-providers/htpasswd file and verify that it includes three entries with hashed passwords: one each for the new_admin, new_developer, and manager users.

[student@workstation ~]$ cat ~/DO280/labs/auth-providers/htpasswd
new_admin:$2y$05$qQaFbpx4hbf4uZe.SMLSduTN8uN4DNJMJ4jE5zXDA57WrTRlpu2QS
new_developer:$apr1$S0TxtLXl$QSRfBIufYP39pKNsIg/nD1
manager:$apr1$HZ/9tC6b$j2OcHHg2GO2SSu1wyGOge.

You must update the secret after adding additional users. Use the oc set data secret command to update the secret. If the command fails, then wait a few moments for the oauth operator to finish reloading, and rerun the command.
```
[student@workstation ~]$ oc set data secret/localusers \
    --from-file htpasswd=~/DO280/labs/auth-providers/htpasswd \
    -n openshift-config
secret/localusers data updated
```
Use the watch command to examine the status of workloads in the openshift-authentication namespace.
```
[student@workstation ~]$ watch oc get all -n openshift-authentication
NAME                                   READY   STATUS    RESTARTS   AGE
pod/oauth-openshift-6d68ffb9dc-6f8dr   1/1     Running   3          2m
...output omitted...
```
A few minutes after you ran the oc set data command, the redeployment starts. Wait until new pods are running. Press Ctrl+C to exit the watch command.
Log in to the cluster as the manager user.
Note
If the authentication fails, then wait a few moments and try again.
```
[student@workstation ~]$ oc login -u manager -p redhat
Login successful.

...output omitted...
```

Create an auth-providers project, and then verify that the new_developer user cannot access the project.

As the manager user, create an auth-providers project.

[student@workstation ~]$ oc new-project auth-providers
Now using project "auth-providers" on server https://api.ocp4.example.com:6443".
...output omitted...

[student@workstation ~]$ oc login -u new_developer -p developer
Login successful.

...output omitted...

Attempt to delete the auth-providers project.

[student@workstation ~]$ oc delete project auth-providers
Error from server (Forbidden): projects.project.openshift.io "auth-providers" is forbidden: User "new_developer" cannot delete resource "projects" in API group "project.openshift.io" in the namespace "auth-providers"

Change the password for the manager user.

[student@workstation ~]$ oc login -u new_admin -p redhat
Login successful.

...output omitted...

Extract the file data from the secret to the ~/DO280/labs/auth-providers/htpasswd file.

[student@workstation ~]$ oc extract secret/localusers -n openshift-config \
    --to ~/DO280/labs/auth-providers/ --confirm
/home/student/DO280/labs/auth-providers/htpasswd

Generate a random user password and assign it to the MANAGER_PASSWD variable.
```
[student@workstation ~]$ MANAGER_PASSWD="$(openssl rand -hex 15)"
```

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

[student@workstation ~]$ htpasswd -b ~/DO280/labs/auth-providers/htpasswd \
    manager ${MANAGER_PASSWD}
Updating password for user manager

Update the secret.

[student@workstation ~]$ oc set data secret/localusers \
    --from-file htpasswd=~/DO280/labs/auth-providers/htpasswd \
    -n openshift-config
secret/localusers data updated

Use the watch command to examine the status of workloads in the openshift-authentication namespace.
```
[student@workstation ~]$ watch oc get all -n openshift-authentication
NAME                                   READY   STATUS    RESTARTS   AGE
pod/oauth-openshift-6d68ffb9dc-6f8dr   1/1     Running   3          2m
...output omitted...
```
A few minutes after you ran the oc set data command, the redeployment starts. Wait until new pods are running. Press Ctrl+C to exit the watch command.
Log in as the manager user to verify the updated password.
```
[student@workstation ~]$ oc login -u manager -p ${MANAGER_PASSWD}
Login successful.

...output omitted...
```
Note
If the authentication fails, then wait a few moments and try again.

Remove the manager user.

[student@workstation ~]$ oc login -u new_admin -p redhat
Login successful.

...output omitted...

Extract the file data from the secret to the ~/DO280/labs/auth-providers/htpasswd file.

[student@workstation ~]$ oc extract secret/localusers -n openshift-config \
    --to ~/DO280/labs/auth-providers/ --confirm
/home/student/DO280/labs/auth-providers/htpasswd

Delete the manager user from the ~/DO280/labs/auth-providers/htpasswd file.

[student@workstation ~]$ htpasswd -D ~/DO280/labs/auth-providers/htpasswd manager
Deleting password for user manager

Update the secret.

[student@workstation ~]$ oc set data secret/localusers \
    --from-file htpasswd=~/DO280/labs/auth-providers/htpasswd \
    -n openshift-config
secret/localusers data updated

Use the watch command to examine the status of workloads in the openshift-authentication namespace.
```
[student@workstation ~]$ watch oc get all -n openshift-authentication
NAME                                   READY   STATUS    RESTARTS   AGE
pod/oauth-openshift-6d68ffb9dc-6f8dr   1/1     Running   3          2m
...output omitted...
```
A few minutes after you ran the oc set data command, the redeployment starts. Wait until new pods are running. Press Ctrl+C to exit the watch command.

[student@workstation ~]$ oc login -u manager -p ${MANAGER_PASSWD}
Login failed (401 Unauthorized)
Verify you have provided correct credentials.

[student@workstation ~]$ oc login -u new_admin -p redhat
Login successful.

...output omitted...

Delete the identity resource for the manager user.

[student@workstation ~]$ oc delete identity "myusers:manager"
identity.user.openshift.io "myusers:manager" deleted

Delete the user resource for the manager user.

[student@workstation ~]$ oc delete user manager
user.user.openshift.io manager deleted

List the current users to verify that you deleted the manager user.

[student@workstation ~]$ oc get users
NAME            UID                                   ...  IDENTITIES
admin           6126c5a9-4d18-4cdf-95f7-b16c3d3e7f24  ...  ...
new_admin       489c7402-d318-4805-b91d-44d786a92fc1  ...  myusers:new_admin
new_developer   8dbae772-1dd4-4242-b2b4-955b005d9022  ...  myusers:new_developer

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

[student@workstation ~]$ oc get identity
NAME                   IDP NAME   IDP USER NAME  USER NAME
                                            USER UID
...                    ...        ...            admin
                                            6126c5a9-4d18-4cdf-95f7-b16c3d3e7f24
myusers:new_admin      myusers    new_admin      new_admin
                                            489c7402-d318-4805-b91d-44d786a92fc1
myusers:new_developer  myusers    new_developer  new_developer
                                            8dbae772-1dd4-4242-b2b4-955b005d9022

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

[student@workstation ~]$ oc extract secret/localusers -n openshift-config --to -
# htpasswd
new_admin:$2y$05$qQaFbpx4hbf4uZe.SMLSduTN8uN4DNJMJ4jE5zXDA57WrTRlpu2QS
new_developer:$apr1$S0TxtLXl$QSRfBIufYP39pKNsIg/nD1

Remove the identity provider and clean up all users.

[student@workstation ~]$ oc login -u admin -p redhatocp
Login successful.

...output omitted...

Delete the auth-providers project.

[student@workstation ~]$ oc delete project auth-providers
project.project.openshift.io "auth-providers" deleted

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

[student@workstation ~]$ oc edit oauth

Delete all the lines under the ldap identity provider definition. Your file should match the following example:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - ldap:
...output omitted...
    type: LDAP
  # Delete all lines below
  - htpasswd:
      fileData:
        name: localusers
    mappingMethod: claim
    name: myusers
    type: HTPasswd

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

oauth.config.openshift.io/cluster edited

Use the watch command to examine the status of workloads in the openshift-authentication namespace.

[student@workstation ~]$ watch oc get all -n openshift-authentication
NAME                                   READY   STATUS    RESTARTS   AGE
pod/oauth-openshift-6d68ffb9dc-6f8dr   1/1     Running   3          2m
...output omitted...

A few minutes after you ran the oc edit command, the redeployment starts. Wait until new pods are running. Press Ctrl+C to exit the watch command.

Delete the localusers secret from the openshift-config namespace.

[student@workstation ~]$ oc delete secret localusers -n openshift-config
secret "localusers" deleted

Delete all identity resources.

[student@workstation ~]$ oc delete identity --all
identity.user.openshift.io "Red Hat Identity Management:dWlk...jb20" deleted
identity.user.openshift.io "myusers:new_admin" deleted
identity.user.openshift.io "myusers:new_developer" deleted

Note

You might see additional identities from previously completed exercises.

Delete all user resources.

[student@workstation ~]$ oc delete user --all
user.user.openshift.io "admin" deleted
user.user.openshift.io "developer" deleted
user.user.openshift.io "new_admin" deleted
user.user.openshift.io "new_developer" deleted

Note

You might see additional users from previously completed exercises.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish auth-providers

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