Preparing for users

After installing OKD, you can further expand and customize your cluster to your requirements, including taking steps to prepare for users.

Understanding identity provider configuration

The OKD control plane includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API.

As an administrator, you can configure OAuth to specify an identity provider after you install your cluster.

About identity providers in OKD

By default, only a kubeadmin user exists on your cluster. To specify an identity provider, you must create a custom resource (CR) that describes that identity provider and add it to the cluster.

OKD user names containing /, :, and % are not supported.

Supported identity providers

You can configure the following types of identity providers:

Identity providerDescription

Configure the htpasswd identity provider to validate user names and passwords against a flat file generated using htpasswd.

Configure the keystone identity provider to integrate your OKD cluster with Keystone to enable shared authentication with an OpenStack Keystone v3 server configured to store users in an internal database.

Configure the ldap identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication.

Configure a basic-authentication identity provider for users to log in to OKD with credentials validated against a remote identity provider. Basic authentication is a generic backend integration mechanism.

Configure a request-header identity provider to identify users from request header values, such as X-Remote-User. It is typically used in combination with an authenticating proxy, which sets the request header value.

Configure a github identity provider to validate user names and passwords against GitHub or GitHub Enterprise’s OAuth authentication server.

Configure a gitlab identity provider to use GitLab.com or any other GitLab instance as an identity provider.

Configure a google identity provider using Google’s OpenID Connect integration.

Configure an oidc identity provider to integrate with an OpenID Connect identity provider using an Authorization Code Flow.

After you define an identity provider, you can use RBAC to define and apply permissions.

Identity provider parameters

The following parameters are common to all identity providers:

ParameterDescription

name

The provider name is prefixed to provider user names to form an identity name.

mappingMethod

Defines how new identities are mapped to users when they log in. Enter one of the following values:

    claim

    The default value. Provisions a user with the identity’s preferred user name. Fails if a user with that user name is already mapped to another identity.

    lookup

    Looks up an existing identity, user identity mapping, and user, but does not automatically provision users or identities. This allows cluster administrators to set up identities and users manually, or using an external process. Using this method requires you to manually provision users.

    generate

    Provisions a user with the identity’s preferred user name. If a user with the preferred user name is already mapped to an existing identity, a unique user name is generated. For example, myuser2. This method should not be used in combination with external processes that require exact matches between OKD user names and identity provider user names, such as LDAP group sync.

    add

    Provisions a user with the identity’s preferred user name. If a user with that user name already exists, the identity is mapped to the existing user, adding to any existing identity mappings for the user. Required when multiple identity providers are configured that identify the same set of users and map to the same user names.

When adding or changing identity providers, you can map identities from the new provider to existing users by setting the mappingMethod parameter to add.

Sample identity provider CR

The following custom resource (CR) shows the parameters and default values that you use to configure an identity provider. This example uses the HTPasswd identity provider.

Sample identity provider CR

  1. apiVersion: config.openshift.io/v1
  2. kind: OAuth
  3. metadata:
  4.   name: cluster
  5. spec:
  6.   identityProviders:
  7.   - name: my_identity_provider (1)
  8.     mappingMethod: claim (2)
  9.     type: HTPasswd
  10.     htpasswd:
  11.       fileData:
  12.         name: htpass-secret (3)
1This provider name is prefixed to provider user names to form an identity name.
2Controls how mappings are established between this provider’s identities and User objects.
3An existing secret containing a file generated using htpasswd.

Using RBAC to define and apply permissions

Understand and apply role-based access control.

RBAC overview

Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project.

Cluster administrators can use the cluster roles and bindings to control who has various access levels to the OKD platform itself and all projects.

Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

Authorization is managed using:

Authorization objectDescription

Rules

Sets of permitted verbs on a set of objects. For example, whether a user or service account can create pods.

Roles

Collections of rules. You can associate, or bind, users and groups to multiple roles.

Bindings

Associations between users and/or groups with a role.

There are two levels of RBAC roles and bindings that control authorization:

RBAC levelDescription

Cluster RBAC

Roles and bindings that are applicable across all projects. Cluster roles exist cluster-wide, and cluster role bindings can reference only cluster roles.

Local RBAC

Roles and bindings that are scoped to a given project. While local roles exist only in a single project, local role bindings can reference both cluster and local roles.

A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level. The cluster role view must be bound to a user using a local role binding for that user to view the project. Create local roles only if a cluster role does not provide the set of permissions needed for a particular situation.

This two-level hierarchy allows reuse across multiple projects through the cluster roles while allowing customization inside of individual projects through local roles.

During evaluation, both the cluster role bindings and the local role bindings are used. For example:

  1. Cluster-wide “allow” rules are checked.

  2. Locally-bound “allow” rules are checked.

  3. Deny by default.

Default cluster roles

OKD includes a set of default cluster roles that you can bind to users and groups cluster-wide or locally.

It is not recommended to manually modify the default cluster roles. Modifications to these system roles can prevent a cluster from functioning properly.

Default cluster roleDescription

admin

A project manager. If used in a local binding, an admin has rights to view any resource in the project and modify any resource in the project except for quota.

basic-user

A user that can get basic information about projects and users.

cluster-admin

A super-user that can perform any action in any project. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project.

cluster-status

A user that can get basic cluster status information.

edit

A user that can modify most objects in a project but does not have the power to view or modify roles or bindings.

self-provisioner

A user that can create their own projects.

view

A user who cannot make any modifications, but can see most objects in a project. They cannot view or modify roles or bindings.

Be mindful of the difference between local and cluster bindings. For example, if you bind the cluster-admin role to a user by using a local role binding, it might appear that this user has the privileges of a cluster administrator. This is not the case. Binding the cluster-admin to a user in a project grants super administrator privileges for only that project to the user. That user has the permissions of the cluster role admin, plus a few additional permissions like the ability to edit rate limits, for that project. This binding can be confusing via the web console UI, which does not list cluster role bindings that are bound to true cluster administrators. However, it does list local role bindings that you can use to locally bind cluster-admin.

The relationships between cluster roles, local roles, cluster role bindings, local role bindings, users, groups and service accounts are illustrated below.

OKD RBAC

Evaluating authorization

OKD evaluates authorization by using:

Identity

The user name and list of groups that the user belongs to.

Action

The action you perform. In most cases, this consists of:

  • Project: The project you access. A project is a Kubernetes namespace with additional annotations that allows a community of users to organize and manage their content in isolation from other communities.

  • Verb : The action itself: get, list, create, update, delete, deletecollection, or watch.

  • Resource name: The API endpoint that you access.

Bindings

The full list of bindings, the associations between users or groups with a role.

OKD evaluates authorization by using the following steps:

  1. The identity and the project-scoped action is used to find all bindings that apply to the user or their groups.

  2. Bindings are used to locate all the roles that apply.

  3. Roles are used to find all the rules that apply.

  4. The action is checked against each rule to find a match.

  5. If no matching rule is found, the action is then denied by default.

Remember that users and groups can be associated with, or bound to, multiple roles at the same time.

Project administrators can use the CLI to view local roles and bindings, including a matrix of the verbs and resources each are associated with.

The cluster role bound to the project administrator is limited in a project through a local binding. It is not bound cluster-wide like the cluster roles granted to the cluster-admin or system:admin.

Cluster roles are roles defined at the cluster level but can be bound either at the cluster level or at the project level.

Cluster role aggregation

The default admin, edit, view, and cluster-reader cluster roles support cluster role aggregation, where the cluster rules for each role are dynamically updated as new rules are created. This feature is relevant only if you extend the Kubernetes API by creating custom resources.

Projects and namespaces

A Kubernetes namespace provides a mechanism to scope resources in a cluster. The Kubernetes documentation has more information on namespaces.

Namespaces provide a unique scope for:

  • Named resources to avoid basic naming collisions.

  • Delegated management authority to trusted users.

  • The ability to limit community resource consumption.

Most objects in the system are scoped by namespace, but some are excepted and have no namespace, including nodes and users.

A project is a Kubernetes namespace with additional annotations and is the central vehicle by which access to resources for regular users is managed. A project allows a community of users to organize and manage their content in isolation from other communities. Users must be given access to projects by administrators, or if allowed to create projects, automatically have access to their own projects.

Projects can have a separate name, displayName, and description.

  • The mandatory name is a unique identifier for the project and is most visible when using the CLI tools or API. The maximum name length is 63 characters.

  • The optional displayName is how the project is displayed in the web console (defaults to name).

  • The optional description can be a more detailed description of the project and is also visible in the web console.

Each project scopes its own set of:

ObjectDescription

Objects

Pods, services, replication controllers, etc.

Policies

Rules for which users can or cannot perform actions on objects.

Constraints

Quotas for each kind of object that can be limited.

Service accounts

Service accounts act automatically with designated access to objects in the project.

Cluster administrators can create projects and delegate administrative rights for the project to any member of the user community. Cluster administrators can also allow developers to create their own projects.

Developers and administrators can interact with projects by using the CLI or the web console.

Default projects

OKD comes with a number of default projects, and projects starting with openshift- are the most essential to users. These projects host master components that run as pods and other infrastructure components. The pods created in these namespaces that have a critical pod annotation are considered critical, and the have guaranteed admission by kubelet. Pods created for master components in these namespaces are already marked as critical.

You cannot assign an SCC to pods created in one of the default namespaces: default, kube-system, kube-public, openshift-node, openshift-infra, and openshift. You cannot use these namespaces for running pods or services.

Viewing cluster roles and bindings

You can use the oc CLI to view cluster roles and bindings by using the oc describe command.

Prerequisites

  • Install the oc CLI.

  • Obtain permission to view the cluster roles and bindings.

Users with the cluster-admin default cluster role bound cluster-wide can perform any action on any resource, including viewing cluster roles and bindings.

Procedure

  1. To view the cluster roles and their associated rule sets:

    1. $ oc describe clusterrole.rbac

    Example output

    ``` Name: admin Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true PolicyRule: Resources Non-Resource URLs Resource Names Verbs

    .packages.apps.redhat.com [] [] [* create update patch delete get list watch] imagestreams [] [] [create delete deletecollection get list patch update watch create get list watch] imagestreams.image.openshift.io [] [] [create delete deletecollection get list patch update watch create get list watch] secrets [] [] [create delete deletecollection get list patch update watch get list watch create delete deletecollection patch update] buildconfigs/webhooks [] [] [create delete deletecollection get list patch update watch get list watch] buildconfigs [] [] [create delete deletecollection get list patch update watch get list watch] buildlogs [] [] [create delete deletecollection get list patch update watch get list watch] deploymentconfigs/scale [] [] [create delete deletecollection get list patch update watch get list watch] deploymentconfigs [] [] [create delete deletecollection get list patch update watch get list watch] imagestreamimages [] [] [create delete deletecollection get list patch update watch get list watch] imagestreammappings [] [] [create delete deletecollection get list patch update watch get list watch] imagestreamtags [] [] [create delete deletecollection get list patch update watch get list watch] processedtemplates [] [] [create delete deletecollection get list patch update watch get list watch] routes [] [] [create delete deletecollection get list patch update watch get list watch] templateconfigs [] [] [create delete deletecollection get list patch update watch get list watch] templateinstances [] [] [create delete deletecollection get list patch update watch get list watch] templates [] [] [create delete deletecollection get list patch update watch get list watch] deploymentconfigs.apps.openshift.io/scale [] [] [create delete deletecollection get list patch update watch get list watch] deploymentconfigs.apps.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] buildconfigs.build.openshift.io/webhooks [] [] [create delete deletecollection get list patch update watch get list watch] buildconfigs.build.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] buildlogs.build.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] imagestreamimages.image.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] imagestreammappings.image.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] imagestreamtags.image.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] routes.route.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] processedtemplates.template.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] templateconfigs.template.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] templateinstances.template.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] templates.template.openshift.io [] [] [create delete deletecollection get list patch update watch get list watch] serviceaccounts [] [] [create delete deletecollection get list patch update watch impersonate create delete deletecollection patch update get list watch] imagestreams/secrets [] [] [create delete deletecollection get list patch update watch] rolebindings [] [] [create delete deletecollection get list patch update watch] roles [] [] [create delete deletecollection get list patch update watch] rolebindings.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] roles.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreams.image.openshift.io/secrets [] [] [create delete deletecollection get list patch update watch] rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] networkpolicies.extensions [] [] [create delete deletecollection patch update create delete deletecollection get list patch update watch get list watch] networkpolicies.networking.k8s.io [] [] [create delete deletecollection patch update create delete deletecollection get list patch update watch get list watch] configmaps [] [] [create delete deletecollection patch update get list watch] endpoints [] [] [create delete deletecollection patch update get list watch] persistentvolumeclaims [] [] [create delete deletecollection patch update get list watch] pods [] [] [create delete deletecollection patch update get list watch] replicationcontrollers/scale [] [] [create delete deletecollection patch update get list watch] replicationcontrollers [] [] [create delete deletecollection patch update get list watch] services [] [] [create delete deletecollection patch update get list watch] daemonsets.apps [] [] [create delete deletecollection patch update get list watch] deployments.apps/scale [] [] [create delete deletecollection patch update get list watch] deployments.apps [] [] [create delete deletecollection patch update get list watch] replicasets.apps/scale [] [] [create delete deletecollection patch update get list watch] replicasets.apps [] [] [create delete deletecollection patch update get list watch] statefulsets.apps/scale [] [] [create delete deletecollection patch update get list watch] statefulsets.apps [] [] [create delete deletecollection patch update get list watch] horizontalpodautoscalers.autoscaling [] [] [create delete deletecollection patch update get list watch] cronjobs.batch [] [] [create delete deletecollection patch update get list watch] jobs.batch [] [] [create delete deletecollection patch update get list watch] daemonsets.extensions [] [] [create delete deletecollection patch update get list watch] deployments.extensions/scale [] [] [create delete deletecollection patch update get list watch] deployments.extensions [] [] [create delete deletecollection patch update get list watch] ingresses.extensions [] [] [create delete deletecollection patch update get list watch] replicasets.extensions/scale [] [] [create delete deletecollection patch update get list watch] replicasets.extensions [] [] [create delete deletecollection patch update get list watch] replicationcontrollers.extensions/scale [] [] [create delete deletecollection patch update get list watch] poddisruptionbudgets.policy [] [] [create delete deletecollection patch update get list watch] deployments.apps/rollback [] [] [create delete deletecollection patch update] deployments.extensions/rollback [] [] [create delete deletecollection patch update] catalogsources.operators.coreos.com [] [] [create update patch delete get list watch] clusterserviceversions.operators.coreos.com [] [] [create update patch delete get list watch] installplans.operators.coreos.com [] [] [create update patch delete get list watch] packagemanifests.operators.coreos.com [] [] [create update patch delete get list watch] subscriptions.operators.coreos.com [] [] [create update patch delete get list watch] buildconfigs/instantiate [] [] [create] buildconfigs/instantiatebinary [] [] [create] builds/clone [] [] [create] deploymentconfigrollbacks [] [] [create] deploymentconfigs/instantiate [] [] [create] deploymentconfigs/rollback [] [] [create] imagestreamimports [] [] [create] localresourceaccessreviews [] [] [create] localsubjectaccessreviews [] [] [create] podsecuritypolicyreviews [] [] [create] podsecuritypolicyselfsubjectreviews [] [] [create] podsecuritypolicysubjectreviews [] [] [create] resourceaccessreviews [] [] [create] routes/custom-host [] [] [create] subjectaccessreviews [] [] [create] subjectrulesreviews [] [] [create] deploymentconfigrollbacks.apps.openshift.io [] [] [create] deploymentconfigs.apps.openshift.io/instantiate [] [] [create] deploymentconfigs.apps.openshift.io/rollback [] [] [create] localsubjectaccessreviews.authorization.k8s.io [] [] [create] localresourceaccessreviews.authorization.openshift.io [] [] [create] localsubjectaccessreviews.authorization.openshift.io [] [] [create] resourceaccessreviews.authorization.openshift.io [] [] [create] subjectaccessreviews.authorization.openshift.io [] [] [create] subjectrulesreviews.authorization.openshift.io [] [] [create] buildconfigs.build.openshift.io/instantiate [] [] [create] buildconfigs.build.openshift.io/instantiatebinary [] [] [create] builds.build.openshift.io/clone [] [] [create] imagestreamimports.image.openshift.io [] [] [create] routes.route.openshift.io/custom-host [] [] [create] podsecuritypolicyreviews.security.openshift.io [] [] [create] podsecuritypolicyselfsubjectreviews.security.openshift.io [] [] [create] podsecuritypolicysubjectreviews.security.openshift.io [] [] [create] jenkins.build.openshift.io [] [] [edit view view admin edit view] builds [] [] [get create delete deletecollection get list patch update watch get list watch] builds.build.openshift.io [] [] [get create delete deletecollection get list patch update watch get list watch] projects [] [] [get delete get delete get patch update] projects.project.openshift.io [] [] [get delete get delete get patch update] namespaces [] [] [get get list watch] pods/attach [] [] [get list watch create delete deletecollection patch update] pods/exec [] [] [get list watch create delete deletecollection patch update] pods/portforward [] [] [get list watch create delete deletecollection patch update] pods/proxy [] [] [get list watch create delete deletecollection patch update] services/proxy [] [] [get list watch create delete deletecollection patch update] routes/status [] [] [get list watch update] routes.route.openshift.io/status [] [] [get list watch update] appliedclusterresourcequotas [] [] [get list watch] bindings [] [] [get list watch] builds/log [] [] [get list watch] deploymentconfigs/log [] [] [get list watch] deploymentconfigs/status [] [] [get list watch] events [] [] [get list watch] imagestreams/status [] [] [get list watch] limitranges [] [] [get list watch] namespaces/status [] [] [get list watch] pods/log [] [] [get list watch] pods/status [] [] [get list watch] replicationcontrollers/status [] [] [get list watch] resourcequotas/status [] [] [get list watch] resourcequotas [] [] [get list watch] resourcequotausages [] [] [get list watch] rolebindingrestrictions [] [] [get list watch] deploymentconfigs.apps.openshift.io/log [] [] [get list watch] deploymentconfigs.apps.openshift.io/status [] [] [get list watch] controllerrevisions.apps [] [] [get list watch] rolebindingrestrictions.authorization.openshift.io [] [] [get list watch] builds.build.openshift.io/log [] [] [get list watch] imagestreams.image.openshift.io/status [] [] [get list watch] appliedclusterresourcequotas.quota.openshift.io [] [] [get list watch] imagestreams/layers [] [] [get update get] imagestreams.image.openshift.io/layers [] [] [get update get] builds/details [] [] [update] builds.build.openshift.io/details [] [] [update]

  1. Name:         basic-user
  2. Labels:       <none>
  3. Annotations:  openshift.io/description: A user that can get basic information about projects.
  4.                   rbac.authorization.kubernetes.io/autoupdate: true
  5. PolicyRule:
  6.     Resources                                           Non-Resource URLs  Resource Names  Verbs
  7.       ---------                                           -----------------  --------------  -----
  8.       selfsubjectrulesreviews                             []                 []              [create]
  9.       selfsubjectaccessreviews.authorization.k8s.io       []                 []              [create]
  10.       selfsubjectrulesreviews.authorization.openshift.io  []                 []              [create]
  11.       clusterroles.rbac.authorization.k8s.io              []                 []              [get list watch]
  12.       clusterroles                                        []                 []              [get list]
  13.       clusterroles.authorization.openshift.io             []                 []              [get list]
  14.       storageclasses.storage.k8s.io                       []                 []              [get list]
  15.       users                                               []                 [~]             [get]
  16.       users.user.openshift.io                             []                 [~]             [get]
  17.       projects                                            []                 []              [list watch]
  18.       projects.project.openshift.io                       []                 []              [list watch]
  19.       projectrequests                                     []                 []              [list]
  20.       projectrequests.project.openshift.io                []                 []              [list]
  22. Name:         cluster-admin
  23. Labels:       kubernetes.io/bootstrapping=rbac-defaults
  24. Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
  25. PolicyRule:
  26. Resources  Non-Resource URLs  Resource Names  Verbs
  27. ---------  -----------------  --------------  -----
  28. *.*        []                 []              [*]
  29.            [*]                []              [*]
  31. ...
  32. ```

  1. To view the current set of cluster role bindings, which shows the users and groups that are bound to various roles:

    1. $ oc describe clusterrolebinding.rbac

    Example output

    ``` Name: alertmanager-main Labels: Annotations: Role: Kind: ClusterRole Name: alertmanager-main Subjects: Kind Name Namespace

    ServiceAccount alertmanager-main openshift-monitoring

  1. Name:         basic-users
  2. Labels:       <none>
  3. Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
  4. Role:
  5.   Kind:  ClusterRole
  6.   Name:  basic-user
  7. Subjects:
  8.   Kind   Name                  Namespace
  9.   ----   ----                  ---------
  10.   Group  system:authenticated
  13. Name:         cloud-credential-operator-rolebinding
  14. Labels:       <none>
  15. Annotations:  <none>
  16. Role:
  17.   Kind:  ClusterRole
  18.   Name:  cloud-credential-operator-role
  19. Subjects:
  20.   Kind            Name     Namespace
  21.   ----            ----     ---------
  22.   ServiceAccount  default  openshift-cloud-credential-operator
  25. Name:         cluster-admin
  26. Labels:       kubernetes.io/bootstrapping=rbac-defaults
  27. Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
  28. Role:
  29.   Kind:  ClusterRole
  30.   Name:  cluster-admin
  31. Subjects:
  32.   Kind   Name            Namespace
  33.   ----   ----            ---------
  34.   Group  system:masters
  37. Name:         cluster-admins
  38. Labels:       <none>
  39. Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
  40. Role:
  41.   Kind:  ClusterRole
  42.   Name:  cluster-admin
  43. Subjects:
  44.   Kind   Name                   Namespace
  45.   ----   ----                   ---------
  46.   Group  system:cluster-admins
  47.   User   system:admin
  50. Name:         cluster-api-manager-rolebinding
  51. Labels:       <none>
  52. Annotations:  <none>
  53. Role:
  54.   Kind:  ClusterRole
  55.   Name:  cluster-api-manager-role
  56. Subjects:
  57.   Kind            Name     Namespace
  58.   ----            ----     ---------
  59.   ServiceAccount  default  openshift-machine-api
  61. ...
  62. ```

Viewing local roles and bindings

You can use the oc CLI to view local roles and bindings by using the oc describe command.

Prerequisites

  • Install the oc CLI.

  • Obtain permission to view the local roles and bindings:

    • Users with the cluster-admin default cluster role bound cluster-wide can perform any action on any resource, including viewing local roles and bindings.

    • Users with the admin default cluster role bound locally can view and manage roles and bindings in that project.

Procedure

  1. To view the current set of local role bindings, which show the users and groups that are bound to various roles for the current project:

    1. $ oc describe rolebinding.rbac

  2. To view the local role bindings for a different project, add the -n flag to the command:

    1. $ oc describe rolebinding.rbac -n joe-project

    Example output

    ``` Name: admin Labels: Annotations: Role: Kind: ClusterRole Name: admin Subjects: Kind Name Namespace

    User kube:admin

  1. Name:         system:deployers
  2. Labels:       <none>
  3. Annotations:  openshift.io/description:
  4.                 Allows deploymentconfigs in this namespace to rollout pods in
  5.                 this namespace.  It is auto-managed by a controller; remove
  6.                 subjects to disa...
  7. Role:
  8.   Kind:  ClusterRole
  9.   Name:  system:deployer
  10. Subjects:
  11.   Kind            Name      Namespace
  12.   ----            ----      ---------
  13.   ServiceAccount  deployer  joe-project
  16. Name:         system:image-builders
  17. Labels:       <none>
  18. Annotations:  openshift.io/description:
  19.                 Allows builds in this namespace to push images to this
  20.                 namespace.  It is auto-managed by a controller; remove subjects
  21.                 to disable.
  22. Role:
  23.   Kind:  ClusterRole
  24.   Name:  system:image-builder
  25. Subjects:
  26.   Kind            Name     Namespace
  27.   ----            ----     ---------
  28.   ServiceAccount  builder  joe-project
  31. Name:         system:image-pullers
  32. Labels:       <none>
  33. Annotations:  openshift.io/description:
  34.                 Allows all pods in this namespace to pull images from this
  35.                 namespace.  It is auto-managed by a controller; remove subjects
  36.                 to disable.
  37. Role:
  38.   Kind:  ClusterRole
  39.   Name:  system:image-puller
  40. Subjects:
  41.   Kind   Name                                Namespace
  42.   ----   ----                                ---------
  43.   Group  system:serviceaccounts:joe-project
  44. ```

Adding roles to users

You can use the oc adm administrator CLI to manage the roles and bindings.

Binding, or adding, a role to users or groups gives the user or group the access that is granted by the role. You can add and remove roles to and from users and groups using oc adm policy commands.

You can bind any of the default cluster roles to local users or groups in your project.

Procedure

  1. Add a role to a user in a specific project:

    1. $ oc adm policy add-role-to-user <role> <user> -n <project>

    For example, you can add the admin role to the alice user in joe project by running:

    1. $ oc adm policy add-role-to-user admin alice -n joe

    You can alternatively apply the following YAML to add the role to the user:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: RoleBinding
    3. metadata:
    4.   name: admin-0
    5.   namespace: joe
    6. roleRef:
    7.   apiGroup: rbac.authorization.k8s.io
    8.   kind: ClusterRole
    9.   name: admin
    10. subjects:
    11. - apiGroup: rbac.authorization.k8s.io
    12.   kind: User
    13.   name: alice

  2. View the local role bindings and verify the addition in the output:

    1. $ oc describe rolebinding.rbac -n <project>

    For example, to view the local role bindings for the joe project:

    1. $ oc describe rolebinding.rbac -n joe

    Example output

    ```

    Name: admin Labels: Annotations: Role: Kind: ClusterRole Name: admin Subjects: Kind Name Namespace

    User kube:admin

  1. Name:         admin-0
  2. Labels:       <none>
  3. Annotations:  <none>
  4. Role:
  5.   Kind:  ClusterRole
  6.   Name:  admin
  7. Subjects:
  8.   Kind  Name   Namespace
  9.   ----  ----   ---------
  10.   User  alice (1)
  13. Name:         system:deployers
  14. Labels:       <none>
  15. Annotations:  openshift.io/description:
  16.                 Allows deploymentconfigs in this namespace to rollout pods in
  17.                 this namespace.  It is auto-managed by a controller; remove
  18.                 subjects to disa...
  19. Role:
  20.   Kind:  ClusterRole
  21.   Name:  system:deployer
  22. Subjects:
  23.   Kind            Name      Namespace
  24.   ----            ----      ---------
  25.   ServiceAccount  deployer  joe
  28. Name:         system:image-builders
  29. Labels:       <none>
  30. Annotations:  openshift.io/description:
  31.                 Allows builds in this namespace to push images to this
  32.                 namespace.  It is auto-managed by a controller; remove subjects
  33.                 to disable.
  34. Role:
  35.   Kind:  ClusterRole
  36.   Name:  system:image-builder
  37. Subjects:
  38.   Kind            Name     Namespace
  39.   ----            ----     ---------
  40.   ServiceAccount  builder  joe
  43. Name:         system:image-pullers
  44. Labels:       <none>
  45. Annotations:  openshift.io/description:
  46.                 Allows all pods in this namespace to pull images from this
  47.                 namespace.  It is auto-managed by a controller; remove subjects
  48.                 to disable.
  49. Role:
  50.   Kind:  ClusterRole
  51.   Name:  system:image-puller
  52. Subjects:
  53.   Kind   Name                                Namespace
  54.   ----   ----                                ---------
  55.   Group  system:serviceaccounts:joe
  56. ```
  58. <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>The <code>alice</code> user has been added to the <code>admins</code> <code>RoleBinding</code>.</td></tr></tbody></table>

Creating a local role

You can create a local role for a project and then bind it to a user.

Procedure

  1. To create a local role for a project, run the following command:

    1. $ oc create role <name> --verb=<verb> --resource=<resource> -n <project>

    In this command, specify:

    • <name>, the local role’s name

    • <verb>, a comma-separated list of the verbs to apply to the role

    • <resource>, the resources that the role applies to

    • <project>, the project name

    For example, to create a local role that allows a user to view pods in the blue project, run the following command:

    1. $ oc create role podview --verb=get --resource=pod -n blue

  2. To bind the new role to a user, run the following command:

    1. $ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue

Creating a cluster role

You can create a cluster role.

Procedure

  1. To create a cluster role, run the following command:

    1. $ oc create clusterrole <name> --verb=<verb> --resource=<resource>

    In this command, specify:

    • <name>, the local role’s name

    • <verb>, a comma-separated list of the verbs to apply to the role

    • <resource>, the resources that the role applies to

    For example, to create a cluster role that allows a user to view pods, run the following command:

    1. $ oc create clusterrole podviewonly --verb=get --resource=pod

Local role binding commands

When you manage a user or group’s associated roles for local role bindings using the following operations, a project may be specified with the -n flag. If it is not specified, then the current project is used.

You can use the following commands for local RBAC management.

Table 1. Local role binding operations
CommandDescription

$ oc adm policy who-can <verb> <resource>

Indicates which users can perform an action on a resource.

$ oc adm policy add-role-to-user <role> <username>

Binds a specified role to specified users in the current project.

$ oc adm policy remove-role-from-user <role> <username>

Removes a given role from specified users in the current project.

$ oc adm policy remove-user <username>

Removes specified users and all of their roles in the current project.

$ oc adm policy add-role-to-group <role> <groupname>

Binds a given role to specified groups in the current project.

$ oc adm policy remove-role-from-group <role> <groupname>

Removes a given role from specified groups in the current project.

$ oc adm policy remove-group <groupname>

Removes specified groups and all of their roles in the current project.

Cluster role binding commands

You can also manage cluster role bindings using the following operations. The -n flag is not used for these operations because cluster role bindings use non-namespaced resources.

Table 2. Cluster role binding operations
CommandDescription

$ oc adm policy add-cluster-role-to-user <role> <username>

Binds a given role to specified users for all projects in the cluster.

$ oc adm policy remove-cluster-role-from-user <role> <username>

Removes a given role from specified users for all projects in the cluster.

$ oc adm policy add-cluster-role-to-group <role> <groupname>

Binds a given role to specified groups for all projects in the cluster.

$ oc adm policy remove-cluster-role-from-group <role> <groupname>

Removes a given role from specified groups for all projects in the cluster.

Creating a cluster admin

The cluster-admin role is required to perform administrator level tasks on the OKD cluster, such as modifying cluster resources.

Prerequisites

  • You must have created a user to define as the cluster admin.

Procedure

  • Define the user as a cluster admin:

    1. $ oc adm policy add-cluster-role-to-user cluster-admin <user>

The kubeadmin user

OKD creates a cluster administrator, kubeadmin, after the installation process completes.

This user has the cluster-admin role automatically applied and is treated as the root user for the cluster. The password is dynamically generated and unique to your OKD environment. After installation completes the password is provided in the installation program’s output. For example:

  1. INFO Install complete!
  2. INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
  3. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
  4. INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
  5. INFO Login to the console with user: kubeadmin, password: <provided>

Removing the kubeadmin user

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

If you follow this procedure before another user is a cluster-admin, then OKD must be reinstalled. It is not possible to undo this command.

Prerequisites

  • You must have configured at least one identity provider.

  • You must have added the cluster-admin role to a user.

  • You must be logged in as an administrator.

Procedure

  • Remove the kubeadmin secrets:

    1. $ oc delete secrets kubeadmin -n kube-system

Image configuration

Understand and configure image registry settings.

Image controller configuration parameters

The image.config.openshift.io/cluster resource holds cluster-wide information about how to handle images. The canonical, and only valid name is cluster. Its spec offers the following configuration parameters.

ParameterDescription

allowedRegistriesForImport

Limits the container image registries from which normal users can import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images or ImageStreamMappings from the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.

Every element of this list contains a location of the registry specified by the registry domain name.

domainName: Specifies a domain name for the registry. If the registry uses a non-standard 80 or 443 port, the port should be included in the domain name as well.

insecure: Insecure indicates whether the registry is secure or insecure. By default, if not otherwise specified, the registry is assumed to be secure.

additionalTrustedCA

A reference to a config map containing additional CAs that should be trusted during image stream import, pod image pull, openshift-image-registry pullthrough, and builds.

The namespace for this config map is openshift-config. The format of the config map is to use the registry hostname as the key, and the PEM-encoded certificate as the value, for each additional registry CA to trust.

externalRegistryHostnames

Provides the hostnames for the default external image registry. The external hostname should be set only when the image registry is exposed externally. The first value is used in publicDockerImageRepository field in image streams. The value must be in hostname[:port] format.

registrySources

Contains configuration that determines how the container runtime should treat individual registries when accessing images for builds and pods. For instance, whether or not to allow insecure access. It does not contain configuration for the internal cluster registry.

insecureRegistries: Registries which do not have a valid TLS certificate or only support HTTP connections. To specify all subdomains, add the asterisk () wildcard character as a prefix to the domain name. For example, .example.com. You can specify an individual repository within a registry. For example: reg1.io/myrepo/myapp:latest.

blockedRegistries: Registries for which image pull and push actions are denied. To specify all subdomains, add the asterisk () wildcard character as a prefix to the domain name. For example, .example.com. You can specify an individual repository within a registry. For example: reg1.io/myrepo/myapp:latest. All other registries are allowed.

allowedRegistries: Registries for which image pull and push actions are allowed. To specify all subdomains, add the asterisk () wildcard character as a prefix to the domain name. For example, .example.com. You can specify an individual repository within a registry. For example: reg1.io/myrepo/myapp:latest. All other registries are blocked.

containerRuntimeSearchRegistries: Registries for which image pull and push actions are allowed using image short names. All other registries are blocked.

Either blockedRegistries or allowedRegistries can be set, but not both.

When the allowedRegistries parameter is defined, all registries, including registry.redhat.io and quay.io registries and the default internal image registry, are blocked unless explicitly listed. When using the parameter, to prevent pod failure, add all registries including the registry.redhat.io and quay.io registries and the internalRegistryHostname to the allowedRegistries list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.

The status field of the image.config.openshift.io/cluster resource holds observed values from the cluster.

ParameterDescription

internalRegistryHostname

Set by the Image Registry Operator, which controls the internalRegistryHostname. It sets the hostname for the default internal image registry. The value must be in hostname[:port] format. For backward compatibility, you can still use the OPENSHIFT_DEFAULT_REGISTRY environment variable, but this setting overrides the environment variable.

externalRegistryHostnames

Set by the Image Registry Operator, provides the external hostnames for the image registry when it is exposed externally. The first value is used in publicDockerImageRepository field in image streams. The values must be in hostname[:port] format.

Configuring image registry settings

You can configure image registry settings by editing the image.config.openshift.io/cluster custom resource (CR). The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster CR for any changes to the registries and reboots the nodes when it detects changes.

Procedure

  1. Edit the image.config.openshift.io/cluster custom resource:

    1. $ oc edit image.config.openshift.io/cluster

    The following is an example image.config.openshift.io/cluster CR:

    1. apiVersion: config.openshift.io/v1
    2. kind: Image (1)
    3. metadata:
    4.   annotations:
    5.     release.openshift.io/create-only: "true"
    6.   creationTimestamp: "2019-05-17T13:44:26Z"
    7.   generation: 1
    8.   name: cluster
    9.   resourceVersion: "8302"
    10.   selfLink: /apis/config.openshift.io/v1/images/cluster
    11.   uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
    12. spec:
    13.   allowedRegistriesForImport: (2)
    14.     - domainName: quay.io
    15.       insecure: false
    16.   additionalTrustedCA: (3)
    17.     name: myconfigmap
    18.   registrySources: (4)
    19.     allowedRegistries:
    20.     - example.com
    21.     - quay.io
    22.     - registry.redhat.io
    23.     - image-registry.openshift-image-registry.svc:5000
    24.     - reg1.io/myrepo/myapp:latest
    25.     insecureRegistries:
    26.     - insecure.com
    27. status:
    28.   internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1Image: Holds cluster-wide information about how to handle images. The canonical, and only valid name is cluster.
    2allowedRegistriesForImport: Limits the container image registries from which normal users may import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images or ImageStreamMappings from the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.
    3additionalTrustedCA: A reference to a config map containing additional certificate authorities (CA) that are trusted during image stream import, pod image pull, openshift-image-registry pullthrough, and builds. The namespace for this config map is openshift-config. The format of the config map is to use the registry hostname as the key, and the PEM certificate as the value, for each additional registry CA to trust.
    4registrySources: Contains configuration that determines whether the container runtime allows or blocks individual registries when accessing images for builds and pods. Either the allowedRegistries parameter or the blockedRegistries parameter can be set, but not both. You can also define whether or not to allow access to insecure registries or registries that allow registries that use image short names. This example uses the allowedRegistries parameter, which defines the registries that are allowed to be used. The insecure registry insecure.com is also allowed. The registrySources paramter does not contain configuration for the internal cluster registry.

    When the allowedRegistries parameter is defined, all registries, including the registry.redhat.io and quay.io registries and the default internal image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, you must add the registry.redhat.io and quay.io registries and the internalRegistryHostname to the allowedRegistries list, as they are required by payload images within your environment. Do not add the registry.redhat.io and quay.io registries to the blockedRegistries list.

    When using the allowedRegistries, blockedRegistries, or insecureRegistries parameter, you can specify an individual repository within a registry. For example: reg1.io/myrepo/myapp:latest.

    Insecure external registries should be avoided to reduce possible security risks.

  2. To check that the changes are applied, list your nodes:

    1. $ oc get nodes

    Example output

    1. NAME                                       STATUS                     ROLES    AGE   VERSION
    2. ci-ln-j5cd0qt-f76d1-vfj5x-master-0         Ready                         master   98m   v1.22.1
    3. ci-ln-j5cd0qt-f76d1-vfj5x-master-1         Ready,SchedulingDisabled      master   99m   v1.22.1
    4. ci-ln-j5cd0qt-f76d1-vfj5x-master-2         Ready                         master   98m   v1.22.1
    5. ci-ln-j5cd0qt-f76d1-vfj5x-worker-b-nsnd4   Ready                         worker   90m   v1.22.1
    6. ci-ln-j5cd0qt-f76d1-vfj5x-worker-c-5z2gz   NotReady,SchedulingDisabled   worker   90m   v1.22.1
    7. ci-ln-j5cd0qt-f76d1-vfj5x-worker-d-stsjv   Ready                         worker   90m   v1.22.1

For more information on the allowed, blocked, and insecure registry parameters, see Configuring image registry settings.

Configuring additional trust stores for image registry access

The image.config.openshift.io/cluster custom resource can contain a reference to a config map that contains additional certificate authorities to be trusted during image registry access.

Prerequisites

  • The certificate authorities (CA) must be PEM-encoded.

Procedure

You can create a config map in the openshift-config namespace and use its name in AdditionalTrustedCA in the image.config.openshift.io custom resource to provide additional CAs that should be trusted when contacting external registries.

The config map key is the hostname of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate is the value, for each additional registry CA to trust.

Image registry CA config map example

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: my-registry-ca
  5. data:
  6.   registry.example.com: |
  7.     -----BEGIN CERTIFICATE-----
  8.     ...
  9.     -----END CERTIFICATE-----
  10.   registry-with-port.example.com..5000: | (1)
  11.     -----BEGIN CERTIFICATE-----
  12.     ...
  13.     -----END CERTIFICATE-----
1If the registry has the port, such as registry-with-port.example.com:5000, : should be replaced with ...

You can configure additional CAs with the following procedure.

  1. To configure an additional CA:

    1. $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    1. $ oc edit image.config.openshift.io cluster
    1. spec:
    2.   additionalTrustedCA:
    3.     name: registry-config

Configuring image registry repository mirroring

Setting up container registry repository mirroring enables you to do the following:

  • Configure your OKD cluster to redirect requests to pull images from a repository on a source image registry and have it resolved by a repository on a mirrored image registry.

  • Identify multiple mirrored repositories for each target repository, to make sure that if one mirror is down, another can be used.

The attributes of repository mirroring in OKD include:

  • Image pulls are resilient to registry downtimes.

  • Clusters in restricted networks can pull images from critical locations, such as quay.io, and have registries behind a company firewall provide the requested images.

  • A particular order of registries is tried when an image pull request is made, with the permanent registry typically being the last one tried.

  • The mirror information you enter is added to the /etc/containers/registries.conf file on every node in the OKD cluster.

  • When a node makes a request for an image from the source repository, it tries each mirrored repository in turn until it finds the requested content. If all mirrors fail, the cluster tries the source repository. If successful, the image is pulled to the node.

Setting up repository mirroring can be done in the following ways:

  • At OKD installation:

    By pulling container images needed by OKD and then bringing those images behind your company’s firewall, you can install OKD into a datacenter that is in a restricted network.

  • After OKD installation:

    Even if you don’t configure mirroring during OKD installation, you can do so later using the ImageContentSourcePolicy object.

The following procedure provides a post-installation mirror configuration, where you create an ImageContentSourcePolicy object that identifies:

  • The source of the container image repository you want to mirror.

  • A separate entry for each mirror repository you want to offer the content requested from the source repository.

You can only configure global pull secrets for clusters that have an ImageContentSourcePolicy object. You cannot add a pull secret to a project.

Prerequisites

  • Access to the cluster as a user with the cluster-admin role.

Procedure

  1. Configure mirrored repositories, by either:

    • Setting up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.

    • Using a tool such as skopeo to copy images manually from the source directory to the mirrored repository.

      For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL) 7 or RHEL 8 system, use the skopeo command as shown in this example:

      1. $ skopeo copy \
      2. docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
      3. docker://example.io/example/ubi-minimal

      In this example, you have a container image registry that is named example.io with an image repository named example to which you want to copy the ubi8/ubi-minimal image from registry.access.redhat.com. After you create the registry, you can configure your OKD cluster to redirect requests made of the source repository to the mirrored repository.

  2. Log in to your OKD cluster.

  3. Create an ImageContentSourcePolicy file (for example, registryrepomirror.yaml), replacing the source and mirrors with your own registry and repository pairs and images:

    1. apiVersion: operator.openshift.io/v1alpha1
    2. kind: ImageContentSourcePolicy
    3. metadata:
    4.   name: ubi8repo
    5. spec:
    6.   repositoryDigestMirrors:
    7.   - mirrors:
    8.     - example.io/example/ubi-minimal (1)
    9.     source: registry.access.redhat.com/ubi8/ubi-minimal (2)
    10.   - mirrors:
    11.     - example.com/example/ubi-minimal
    12.     source: registry.access.redhat.com/ubi8/ubi-minimal
    13.   - mirrors:
    14.     - mirror.example.com/redhat
    15.     source: registry.redhat.io/openshift4 (3)
    1Indicates the name of the image registry and repository.
    2Indicates the registry and repository containing the content that is mirrored.
    3You can configure a namespace inside a registry to use any image in that namespace. If you use a registry domain as a source, the ImageContentSourcePolicy resource is applied to all repositories from the registry.

  4. Create the new ImageContentSourcePolicy object:

    1. $ oc create -f registryrepomirror.yaml

    After the ImageContentSourcePolicy object is created, the new settings are deployed to each node and the cluster starts using the mirrored repository for requests to the source repository.

  5. To check that the mirrored configuration settings, are applied, do the following on one of the nodes.

    1. List your nodes:

      1. $ oc get node

      Example output

      1. NAME                           STATUS                     ROLES    AGE  VERSION
      2. ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.22.1
      3. ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.22.1
      4. ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.22.1
      5. ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.22.1
      6. ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.22.1
      7. ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.22.1

      You can see that scheduling on each worker node is disabled as the change is being applied.

    2. Start the debugging process to access the node:

      1. $ oc debug node/ip-10-0-147-35.ec2.internal

      Example output

      1. Starting pod/ip-10-0-147-35ec2internal-debug ...
      2. To use host binaries, run `chroot /host`

    3. Access the node’s files:

      1. sh-4.2# chroot /host

    4. Check the /etc/containers/registries.conf file to make sure the changes were made:

      1. sh-4.2# cat /etc/containers/registries.conf

      Example output

      1. unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      2. [[registry]]
      3.   location = "registry.access.redhat.com/ubi8/"
      4.   insecure = false
      5.   blocked = false
      6.   mirror-by-digest-only = true
      7.   prefix = ""
      9.   [[registry.mirror]]
      10.     location = "example.io/example/ubi8-minimal"
      11.     insecure = false
      13.   [[registry.mirror]]
      14.     location = "example.com/example/ubi8-minimal"
      15.     insecure = false

    5. Pull an image digest to the node from the source and check if it is resolved by the mirror. ImageContentSourcePolicy objects support image digests only, not image tags.

      1. sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

Troubleshooting repository mirroring

If the repository mirroring procedure does not work as described, use the following information about how repository mirroring works to help troubleshoot the problem.

  • The first working mirror is used to supply the pulled image.

  • The main registry is only used if no other mirror works.

  • From the system context, the Insecure flags are used as fallback.

  • The format of the /etc/containers/registries.conf file has changed recently. It is now version 2 and in TOML format.

Populating OperatorHub from mirrored Operator catalogs

If you mirrored Operator catalogs for use with disconnected clusters, you can populate OperatorHub with the Operators from your mirrored catalogs. You can use the generated manifests from the mirroring process to create the required ImageContentSourcePolicy and CatalogSource objects.

Prerequistes

Creating the ImageContentSourcePolicy object

After mirroring Operator catalog content to your mirror registry, create the required ImageContentSourcePolicy (ICSP) object. The ICSP object configures nodes to translate between the image references stored in Operator manifests and the mirrored registry.

Procedure

  • On a host with access to the disconnected cluster, create the ICSP by running the following command to specify the imageContentSourcePolicy.yaml file in your manifests directory:

    1. $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

    where <path/to/manifests/dir> is the path to the manifests directory for your mirrored content.

    Applying the ICSP causes all worker nodes in the cluster to restart. You must wait for this reboot process to finish cycling through each of your worker nodes before proceeding.

You can now create a CatalogSource object to reference your mirrored index image and Operator content.

Adding a catalog source to a cluster

Adding a catalog source to an OKD cluster enables the discovery and installation of Operators for users. Cluster administrators can create a CatalogSource object that references an index image. OperatorHub uses catalog sources to populate the user interface.

Prerequisites

  • An index image built and pushed to a registry.

Procedure

  1. Create a CatalogSource object that references your index image. If you used the oc adm catalog mirror command to mirror your catalog to a target registry, you can use the generated catalogSource.yaml file in your manifests directory as a starting point.

    1. Modify the following to your specifications and save it as a catalogSource.yaml file:

      1. apiVersion: operators.coreos.com/v1alpha1
      2. kind: CatalogSource
      3. metadata:
      4.   name: my-operator-catalog (1)
      5.   namespace: olm (2)
      6. spec:
      7.   sourceType: grpc
      8.   image: <registry>/<namespace>/catalog:latest (3)
      9.   displayName: My Operator Catalog
      10.   publisher: <publisher_name> (4)
      11.   updateStrategy:
      12.     registryPoll: (5)
      13.       interval: 30m
      1If you want the catalog source to be available globally to users in all namespaces, specify the olm namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
      2If you mirrored content to local files before uploading to a registry, remove any backslash (/) characters from the metadata.name field to avoid an “invalid resource name” error when you create the object.
      3Specify your index image.
      4Specify your name or an organization name publishing the catalog.
      5Catalog sources can automatically check for new versions to keep up to date.

    2. Use the file to create the CatalogSource object:

      1. $ oc apply -f catalogSource.yaml

  2. Verify the following resources are created successfully.

    1. Check the pods:

      1. $ oc get pods -n olm

      Example output

      1. NAME                                    READY   STATUS    RESTARTS  AGE
      2. my-operator-catalog-6njx6               1/1     Running   0         28s
      3. marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. Check the catalog source:

      1. $ oc get catalogsource -n olm

      Example output

      1. NAME                  DISPLAY               TYPE PUBLISHER  AGE
      2. my-operator-catalog   My Operator Catalog   grpc            5s

    3. Check the package manifest:

      1. $ oc get packagemanifest -n olm

      Example output

      1. NAME                          CATALOG               AGE
      2. jaeger-product                My Operator Catalog   93s

You can now install the Operators from the OperatorHub page on your OKD web console.

About Operator installation with OperatorHub

OperatorHub is a user interface for discovering Operators; it works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster.

As a cluster administrator, you can install an Operator from OperatorHub using the OKD web console or CLI. Subscribing an Operator to one or more namespaces makes the Operator available to developers on your cluster.

During installation, you must determine the following initial settings for the Operator:

Installation Mode

Choose All namespaces on the cluster (default) to have the Operator installed on all namespaces or choose individual namespaces, if available, to only install the Operator on selected namespaces. This example chooses All namespaces…​ to make the Operator available to all users and projects.

Update Channel

If an Operator is available through multiple channels, you can choose which channel you want to subscribe to. For example, to deploy from the stable channel, if available, select it from the list.

Approval Strategy

You can choose automatic or manual updates.

If you choose automatic updates for an installed Operator, when a new version of that Operator is available in the selected channel, Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without human intervention.

If you select manual updates, when a newer version of an Operator is available, OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the Operator updated to the new version.

Configuring OKD to use Red Hat Operators

In OKD, Red Hat Operators are not available by default. You can access and install these Operators if you have a pull secret from the Red Hat OpenShift Cluster Manager site by editing the OperatorHub custom resource (CR).

Prerequisites

Procedure

To access the Red Hat Operators in an OKD cluster:

  1. Edit the OperatorHub CR using the web console or CLI:

    1. Using the CLI:

      1. Edit the OperatorHub CR:

        1. $ oc edit OperatorHub cluster

      2. Add redhat-operators to the list of sources as disabled: false:

        Example OperatorHub CR

        1. apiVersion: config.openshift.io/v1
        2. kind: OperatorHub
        3. metadata:
        4.   name: cluster
        5. spec:
        6.   disableAllDefaultSources: true
        7.   sources:
        8.   - disabled: false (1)
        9.     name: redhat-operators
        10.   - disabled: false
        11.     name: community-operators
        1Add the name: redhat-operators and disabled: false parameters.

    2. Using the web console:

      1. Switch to the Administration → Custom Resource Definitions page.

      2. On the Custom Resource Definitions page, click OperatorHub.

      3. On the Custom Resource Definition Overview page, click Instances.

      4. On the Instances tab, click cluster.

      5. On the Instances tab, click YAML.

      6. In the YAML field, add redhat-operators to the list of sources as disabled: false:

        Example OperatorHub CR

        1. apiVersion: config.openshift.io/v1
        2. kind: OperatorHub
        3. metadata:
        4.   name: cluster
        5. spec:
        6.   disableAllDefaultSources: true
        7.   sources:
        8.   - disabled: false (1)
        9.     name: redhat-operators
        10.   - disabled: false
        11.     name: community-operators
        1Add the name: redhat-operators and disabled: false parameters.

      7. Click Save.

  1. Log out of the web console, and then log back in.

Installing from OperatorHub using the web console

You can install and subscribe to an Operator from OperatorHub using the OKD web console.

Prerequisites

  • Access to an OKD cluster using an account with cluster-admin permissions.

Procedure

  1. Navigate in the web console to the Operators → OperatorHub page.

  2. Scroll or type a keyword into the Filter by keyword box to find the Operator you want. For example, type jaeger to find the Jaeger Operator.

    You can also filter options by Infrastructure Features. For example, select Disconnected if you want to see Operators that work in disconnected environments, also known as restricted network environments.

  3. Select the Operator to display additional information.

    Choosing a Community Operator warns that Red Hat does not certify Community Operators; you must acknowledge the warning before continuing.

  4. Read the information about the Operator and click Install.

  5. On the Install Operator page:

    1. Select one of the following:

      • All namespaces on the cluster (default) installs the Operator in the default openshift-operators namespace to watch and be made available to all namespaces in the cluster. This option is not always available.

      • A specific namespace on the cluster allows you to choose a specific, single namespace in which to install the Operator. The Operator will only watch and be made available for use in this single namespace.

    2. Select an Update Channel (if more than one is available).

    3. Select Automatic or Manual approval strategy, as described earlier.

  6. Click Install to make the Operator available to the selected namespaces on this OKD cluster.

    1. If you selected a Manual approval strategy, the upgrade status of the subscription remains Upgrading until you review and approve the install plan.

      After approving on the Install Plan page, the subscription upgrade status moves to Up to date.

    2. If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention.

  7. After the upgrade status of the subscription is Up to date, select Operators → Installed Operators to verify that the cluster service version (CSV) of the installed Operator eventually shows up. The Status should ultimately resolve to InstallSucceeded in the relevant namespace.

    For the All namespaces…​ installation mode, the status resolves to InstallSucceeded in the openshift-operators namespace, but the status is Copied if you check in other namespaces.

    If it does not:

    1. Check the logs in any pods in the openshift-operators project (or other relevant namespace if A specific namespace…​ installation mode was selected) on the Workloads → Pods page that are reporting issues to troubleshoot further.

Installing from OperatorHub using the CLI

Instead of using the OKD web console, you can install an Operator from OperatorHub using the CLI. Use the oc command to create or update a Subscription object.

Prerequisites

  • Access to an OKD cluster using an account with cluster-admin permissions.

  • Install the oc command to your local system.

Procedure

  1. View the list of Operators available to the cluster from OperatorHub:

    1. $ oc get packagemanifests -n openshift-marketplace

    Example output

    1. NAME                               CATALOG               AGE
    2. 3scale-operator                    Red Hat Operators     91m
    3. advanced-cluster-management        Red Hat Operators     91m
    4. amq7-cert-manager                  Red Hat Operators     91m
    5. ...
    6. couchbase-enterprise-certified     Certified Operators   91m
    7. crunchy-postgres-operator          Certified Operators   91m
    8. mongodb-enterprise                 Certified Operators   91m
    9. ...
    10. etcd                               Community Operators   91m
    11. jaeger                             Community Operators   91m
    12. kubefed                            Community Operators   91m
    13. ...

    Note the catalog for your desired Operator.

  2. Inspect your desired Operator to verify its supported install modes and available channels:

    1. $ oc describe packagemanifests <operator_name> -n openshift-marketplace

  3. An Operator group, defined by an OperatorGroup object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group.

    The namespace to which you subscribe the Operator must have an Operator group that matches the install mode of the Operator, either the AllNamespaces or SingleNamespace mode. If the Operator you intend to install uses the AllNamespaces, then the openshift-operators namespace already has an appropriate Operator group in place.

    However, if the Operator uses the SingleNamespace mode and you do not already have an appropriate Operator group in place, you must create one.

    The web console version of this procedure handles the creation of the OperatorGroup and Subscription objects automatically behind the scenes for you when choosing SingleNamespace mode.

    1. Create an OperatorGroup object YAML file, for example operatorgroup.yaml:

      Example OperatorGroup object

      1. apiVersion: operators.coreos.com/v1
      2. kind: OperatorGroup
      3. metadata:
      4.   name: <operatorgroup_name>
      5.   namespace: <namespace>
      6. spec:
      7.   targetNamespaces:
      8.   - <namespace>

    2. Create the OperatorGroup object:

      1. $ oc apply -f operatorgroup.yaml

  4. Create a Subscription object YAML file to subscribe a namespace to an Operator, for example sub.yaml:

    Example Subscription object

    1. apiVersion: operators.coreos.com/v1alpha1
    2. kind: Subscription
    3. metadata:
    4.   name: <subscription_name>
    5.   namespace: openshift-operators (1)
    6. spec:
    7.   channel: <channel_name> (2)
    8.   name: <operator_name> (3)
    9.   source: redhat-operators (4)
    10.   sourceNamespace: openshift-marketplace (5)
    1For AllNamespaces install mode usage, specify the openshift-operators namespace. Otherwise, specify the relevant single namespace for SingleNamespace install mode usage.
    2Name of the channel to subscribe to.
    3Name of the Operator to subscribe to.
    4Name of the catalog source that provides the Operator.
    5Namespace of the catalog source. Use openshift-marketplace for the default OperatorHub catalog sources.

  5. Create the Subscription object:

    1. $ oc apply -f sub.yaml

    At this point, OLM is now aware of the selected Operator. A cluster service version (CSV) for the Operator should appear in the target namespace, and APIs provided by the Operator should be available for creation.

Additional resources