Chapter 5. Cluster extensions

Procedure

1. To return a list of extensions that support the AllNamespaces install mode and do not use webhooks, enter the following command:

   $ opm render <catalog_registry_url>:<tag> \
     | jq -cs '[.[] | select(.schema == "olm.bundle" \
     and (.properties[] | select(.type == "olm.csv.metadata").value.installModes[] \
     | select(.type == "AllNamespaces" and .supported == true)) \
     and .spec.webhookdefinitions == null) | .package] | unique[]'

   where:

   catalog_registry_url

   Specifies the URL of the catalog registry, such as registry.redhat.io/redhat/redhat-operator-index.

   tag

   Specifies the tag or version of the catalog, such as v5.0 or latest.

   Example command

   $ opm render \
     registry.redhat.io/redhat/redhat-operator-index:v5.0 \
     | jq -cs '[.[] | select(.schema == "olm.bundle" \
     and (.properties[] | select(.type == "olm.csv.metadata").value.installModes[] \
     | select(.type == "AllNamespaces" and .supported == true)) \
     and .spec.webhookdefinitions == null) | .package] | unique[]'

   Example output

   "3scale-operator"
   "amq-broker-rhel8"
   "amq-online"
   "amq-streams"
   "amq-streams-console"
   "ansible-automation-platform-operator"
   "ansible-cloud-addons-operator"
   "apicast-operator"
   "authorino-operator"
   "aws-load-balancer-operator"
   "bamoe-kogito-operator"
   "cephcsi-operator"
   "cincinnati-operator"
   "cluster-logging"
   "cluster-observability-operator"
   "compliance-operator"
   "container-security-operator"
   "cryostat-operator"
   "datagrid"
   "devspaces"
   ...

2. Inspect the contents of an extension’s metadata by running the following command:

   $ opm render <catalog_registry_url>:<tag> \
     | jq -s '.[] | select( .schema == "olm.package") \
     | select( .name == "<package_name>")'

   Example command

   $ opm render \
     registry.redhat.io/redhat/redhat-operator-index:v5.0 \
     | jq -s '.[] | select( .schema == "olm.package") \
     | select( .name == "openshift-pipelines-operator-rh")'

   Example output

   {
     "schema": "olm.package",
     "name": "openshift-pipelines-operator-rh",
     "defaultChannel": "latest",
     "icon": {
       "base64data": "iVBORw0KGgoAAAANSUhE...",
       "mediatype": "image/png"
     }
   }

Procedure

1. Create a CR, similar to the following example:

   apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     name: <clusterextension_name>
   spec:
     namespace: <installed_namespace>
     source:
       sourceType: Catalog
       catalog:
         packageName: <package_name>
         channels:
           - <channel_name>
         version: <version_or_version_range>
         upgradeConstraintPolicy: CatalogProvided

   where:

   spec.namespace

   Specifies the namespace where you want the bundle installed, such as pipelines or my-extension. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.

   spec.source.catalog.channels

   Specifies channel names as an array, such as pipelines-1.14 or latest. This field is optional.

   spec.source.catalog.version

   Specifies the version or version range, such as 1.14.0, 1.14.x, or >=1.16, of the package you want to install or update. This field is optional.

   spec.source.catalog.upgradeConstraintPolicy

   Specifies the upgrade constraint policy. If unspecified, the default setting is CatalogProvided. The CatalogProvided setting only updates if the new version satisfies the upgrade constraints set by the package author. To force an update or rollback, set the field to SelfCertified. This field is optional.

   Example pipelines-operator.yaml CR

   apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     name: pipelines-operator
   spec:
     namespace: pipelines
     source:
       sourceType: Catalog
       catalog:
         packageName: openshift-pipelines-operator-rh
         version: "1.14.x"

2. Apply the CR to the cluster by running the following command:

   $ oc apply -f pipelines-operator.yaml

   Example output

   clusterextension.olm.operatorframework.io/pipelines-operator created

Verification

1. View the Operator or extension’s CR in the YAML format by running the following command:

   $ oc get clusterextension pipelines-operator -o yaml

   Example output

   apiVersion: v1
   items:
   - apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       annotations:
         kubectl.kubernetes.io/last-applied-configuration: |
           {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
       creationTimestamp: "2025-02-18T21:48:13Z"
       finalizers:
       - olm.operatorframework.io/cleanup-unpack-cache
       - olm.operatorframework.io/cleanup-contentmanager-cache
       generation: 1
       name: pipelines-operator
       resourceVersion: "72725"
       uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
     spec:
       namespace: pipelines
       source:
         catalog:
           packageName: openshift-pipelines-operator-rh
           upgradeConstraintPolicy: CatalogProvided
           version: 1.14.x
         sourceType: Catalog
     status:
       conditions:
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: Deprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: PackageDeprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: ChannelDeprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: BundleDeprecated
       - lastTransitionTime: "2025-02-18T21:48:16Z"
         message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
           successfully
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Installed
       - lastTransitionTime: "2025-02-18T21:48:16Z"
         message: desired state reached
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Progressing
       install:
         bundle:
           name: openshift-pipelines-operator-rh.v1.14.5
           version: 1.14.5
   kind: List
   metadata:
     resourceVersion: ""

   where:

   spec.channel

   Displays the channel defined in the CR of the extension.

   spec.version

   Displays the version or version range defined in the CR of the extension.

   status.conditions

   Displays information about the status and health of the extension.

   type: Deprecated

   Displays whether one or more of following are deprecated:

   type: PackageDeprecated

   Displays whether the resolved package is deprecated.

   type: ChannelDeprecated

   Displays whether the resolved channel is deprecated.

   type: BundleDeprecated

   Displays whether the resolved bundle is deprecated.

   The value of False in the status field indicates that the reason: Deprecated condition is not deprecated. The value of True in the status field indicates that the reason: Deprecated condition is deprecated.

   installedBundle.name

   Displays the name of the bundle installed.

   installedBundle.version

   Displays the version of the bundle installed.

Procedure

1. Create a custom resource (CR) based on where you want the extension to watch for resources:

   • To configure the extension to watch its own installation namespace:

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: <extension_name>
     spec:
       namespace: <installation_namespace>
       config:
         configType: Inline
         inline:
           watchNamespace: <installation_namespace>
       source:
         sourceType: Catalog
         catalog:
           packageName: <package_name>
           version: <version>
           upgradeConstraintPolicy: CatalogProvided

     where:

     config.inline.watchNamespace

     Specifies the namespace to watch for resources. For requirements and valid values, see "Extension configuration".

   • To configure the extension to watch a different namespace:

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: <extension_name>
     spec:
       namespace: <installation_namespace>
       config:
         configType: Inline
         inline:
           watchNamespace: <watched_namespace>
       source:
         sourceType: Catalog
         catalog:
           packageName: <package_name>
           version: <version>
           upgradeConstraintPolicy: CatalogProvided

2. Apply the CR to the cluster by running the following command:

   $ oc apply -f <cluster_extension_cr>.yaml

Procedure

1. Inspect a package for channel and version information from a local copy of your catalog file by completing the following steps:

   1. Get a list of channels from a selected package by running the following command:

      $ opm render <catalog_registry_url>:<tag> \
        | jq -s '.[] | select( .schema == "olm.channel" ) \
        | select( .package == "openshift-pipelines-operator-rh") | .name'

      Example command

      $ opm render registry.redhat.io/redhat/redhat-operator-index:v5.0 \
        | jq -s '.[] | select( .schema == "olm.channel" ) \
        | select( .package == "openshift-pipelines-operator-rh") | .name'

      Example output

      "latest"
      "pipelines-1.14"
      "pipelines-1.15"
      "pipelines-1.16"
      "pipelines-1.17"

   2. Get a list of the versions published in a channel by running the following command:

      $ opm render <catalog_registry_url>:<tag> \
        | jq -s '.[] | select( .package == "<package_name>" ) \
        | select( .schema == "olm.channel" ) \
        | select( .name == "<channel_name>" ) | .entries \
        | .[] | .name'

      Example command

      $ opm render registry.redhat.io/redhat/redhat-operator-index:v5.0 \
        | jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) \
        | select( .schema == "olm.channel" ) | select( .name == "latest" ) \
        | .entries | .[] | .name'

      Example output

      "openshift-pipelines-operator-rh.v1.15.0"
      "openshift-pipelines-operator-rh.v1.16.0"
      "openshift-pipelines-operator-rh.v1.17.0"
      "openshift-pipelines-operator-rh.v1.17.1"

2. Find out what version or channel is specified in your Operator or extension’s CR by running the following command:

   $ oc get clusterextension <operator_name> -o yaml

   Example command

   $ oc get clusterextension pipelines-operator -o yaml

   Example output

   apiVersion: v1
   items:
   - apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       annotations:
         kubectl.kubernetes.io/last-applied-configuration: |
           {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
       creationTimestamp: "2025-02-18T21:48:13Z"
       finalizers:
       - olm.operatorframework.io/cleanup-unpack-cache
       - olm.operatorframework.io/cleanup-contentmanager-cache
       generation: 1
       name: pipelines-operator
       resourceVersion: "72725"
       uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
     spec:
       namespace: pipelines
       source:
         catalog:
           packageName: openshift-pipelines-operator-rh
           upgradeConstraintPolicy: CatalogProvided
           version: 1.14.x
         sourceType: Catalog
     status:
       conditions:
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: Deprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: PackageDeprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: ChannelDeprecated
       - lastTransitionTime: "2025-02-18T21:48:13Z"
         message: ""
         observedGeneration: 1
         reason: Deprecated
         status: "False"
         type: BundleDeprecated
       - lastTransitionTime: "2025-02-18T21:48:16Z"
         message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
           successfully
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Installed
       - lastTransitionTime: "2025-02-18T21:48:16Z"
         message: desired state reached
         observedGeneration: 1
         reason: Succeeded
         status: "True"
         type: Progressing
       install:
         bundle:
           name: openshift-pipelines-operator-rh.v1.14.5
           version: 1.14.5
   kind: List
   metadata:
     resourceVersion: ""

3. Edit your CR by using one of the following methods:

   • If you want to pin your Operator or extension to specific version, such as 1.15.0, edit your CR similar to the following example:

     Example pipelines-operator.yaml CR

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       namespace: pipelines
       source:
         sourceType: Catalog
         catalog:
           packageName: openshift-pipelines-operator-rh
           version: "1.15.0"

     This example updates the version from 1.14.x to 1.15.0.

   • If you want to define a range of acceptable update versions, edit your CR similar to the following example:

     Example CR with a version range specified

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       namespace: pipelines
       source:
         sourceType: Catalog
         catalog:
           packageName: openshift-pipelines-operator-rh
           version: ">1.15, <1.17"

     The spec.source.catalog.version value specifies that the desired version range is greater than version 1.15 and less than 1.17.

   • If you want to update to the latest version that can be resolved from a channel, edit your CR similar to the following example:

     Example CR with a specified channel

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       namespace: pipelines
       source:
         sourceType: Catalog
         catalog:
           packageName: openshift-pipelines-operator-rh
           channels:
             - latest

     The spec.source.catalog.channels value installs the latest release that can be resolved from the specified channel. Updates to the channel are automatically installed. Enter values as an array.

   • If you want to specify a channel and version or version range, edit your CR similar to the following example:

     Example CR with a specified channel and version range

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: pipelines-operator
     spec:
       namespace: pipelines
       source:
         sourceType: Catalog
         catalog:
           packageName: openshift-pipelines-operator-rh
           channels:
             - latest
           version: "<1.16"

     For more information, see "Example custom resources (CRs) that specify a target version".

4. Apply the update to the cluster by running the following command:

   $ oc apply -f pipelines-operator.yaml

   Example output

   clusterextension.olm.operatorframework.io/pipelines-operator configured

Procedure

1. Inspect the available versions and images of the extension you want to install by running the following command:

   $ opm render <registry_url>:<tag_or_version> | \
     jq -cs '.[] | select( .schema == "olm.bundle" ) | \
     select( .package == "<extension_name>") | \
     {"name":.name, "image":.image}'

   Example command

   $ opm render registry.redhat.io/redhat/redhat-operator-index:v5.0 | \
     jq -cs '.[] | select( .schema == "olm.bundle" ) | \
     select( .package == "openshift-pipelines-operator-rh") | \
     {"name":.name, "image":.image}'

   Example output

   {"name":"openshift-pipelines-operator-rh.v1.14.5","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838"}

2. Make a directory to extract the image of the bundle that you want to install by running the following command:

   $ mkdir <new_dir>

3. Change into the directory by running the following command:

   $ cd <new_dir>

4. Find the image reference of the version that you want to install and run the following command:

   $ oc image extract <full_path_to_registry_image>@sha256:<sha>

   Example command

   $ oc image extract registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838

5. Change into the manifests directory by running the following command:

   $ cd manifests

6. View the contents of the manifests directory by entering the following command. The output lists the manifests of the resources required to install, manage, and operate your extension.

   $ tree

   Example output

   .
   ├── manifests
   │   ├── config-logging_v1_configmap.yaml
   │   ├── openshift-pipelines-operator-monitor_monitoring.coreos.com_v1_servicemonitor.yaml
   │   ├── openshift-pipelines-operator-prometheus-k8s-read-binding_rbac.authorization.k8s.io_v1_rolebinding.yaml
   │   ├── openshift-pipelines-operator-read_rbac.authorization.k8s.io_v1_role.yaml
   │   ├── openshift-pipelines-operator-rh.clusterserviceversion.yaml
   │   ├── operator.tekton.dev_manualapprovalgates.yaml
   │   ├── operator.tekton.dev_openshiftpipelinesascodes.yaml
   │   ├── operator.tekton.dev_tektonaddons.yaml
   │   ├── operator.tekton.dev_tektonchains.yaml
   │   ├── operator.tekton.dev_tektonconfigs.yaml
   │   ├── operator.tekton.dev_tektonhubs.yaml
   │   ├── operator.tekton.dev_tektoninstallersets.yaml
   │   ├── operator.tekton.dev_tektonpipelines.yaml
   │   ├── operator.tekton.dev_tektonresults.yaml
   │   ├── operator.tekton.dev_tektontriggers.yaml
   │   ├── tekton-config-defaults_v1_configmap.yaml
   │   ├── tekton-config-observability_v1_configmap.yaml
   │   ├── tekton-config-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
   │   ├── tekton-config-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
   │   ├── tekton-operator-controller-config-leader-election_v1_configmap.yaml
   │   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_rolebinding.yaml
   │   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_role.yaml
   │   ├── tekton-operator-info_v1_configmap.yaml
   │   ├── tekton-operator_v1_service.yaml
   │   ├── tekton-operator-webhook-certs_v1_secret.yaml
   │   ├── tekton-operator-webhook-config-leader-election_v1_configmap.yaml
   │   ├── tekton-operator-webhook_v1_service.yaml
   │   ├── tekton-result-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
   │   └── tekton-result-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
   ├── metadata
   │   ├── annotations.yaml
   │   └── properties.yaml
   └── root
       └── buildinfo
           ├── content_manifests
           │   └── openshift-pipelines-operator-bundle-container-v1.16.2-3.json
           └── Dockerfile-openshift-pipelines-pipelines-operator-bundle-container-v1.16.2-3

Procedure

1. Render the bundle metadata by running the following command:

   $ opm render <bundle_image> -o json | \
     jq 'select(.schema == "olm.bundle") | .properties[] | select(.type == "olm.bundle.object")'

   Example output

   {
     "type": "olm.bundle.object",
     "value": {
       "data": "...",
       "ref": "olm.csv"
     }
   }

2. Decode the base64-encoded CSV data to view install mode declarations:

   $ echo "<base64_data>" | base64 -d | jq '.spec.installModes'

   Example output

   [
     {
       "type": "OwnNamespace",
       "supported": true
     },
     {
       "type": "SingleNamespace",
       "supported": true
     },
     {
       "type": "MultiNamespace",
       "supported": false
     },
     {
       "type": "AllNamespaces",
       "supported": false
     }
   ]

   In this example, the bundle supports both OwnNamespace and SingleNamespace modes. The .spec.config.inline.watchNamespace field is required and can match or differ from the .spec.namespace field.

Procedure

1. Create a custom resource (CR) based on where you want the extension to watch for resources:

   • To configure the extension to watch its own installation namespace:

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: <extension_name>
     spec:
       namespace: <installation_namespace>
       config:
         configType: Inline
         inline:
           watchNamespace: <installation_namespace>
       source:
         sourceType: Catalog
         catalog:
           packageName: <package_name>
           version: <version>
           upgradeConstraintPolicy: CatalogProvided

     where:

     config.inline.watchNamespace

     Specifies the namespace to watch for resources. For requirements and valid values, see "Extension configuration".

   • To configure the extension to watch a different namespace:

     apiVersion: olm.operatorframework.io/v1
     kind: ClusterExtension
     metadata:
       name: <extension_name>
     spec:
       namespace: <installation_namespace>
       config:
         configType: Inline
         inline:
           watchNamespace: <watched_namespace>
       source:
         sourceType: Catalog
         catalog:
           packageName: <package_name>
           version: <version>
           upgradeConstraintPolicy: CatalogProvided

2. Apply the CR to the cluster by running the following command:

   $ oc apply -f <cluster_extension_cr>.yaml

Procedure

1. List all ClusterObjectSets in the cluster by entering the following command:

   $ oc get clusterobjectsets

2. List ClusterObjectSets for a specific extension by running the following command:

   $ oc get clusterobjectsets -l olm.operatorframework.io/owner-name=<extension_name>

   Replace <extension_name> with your ClusterExtension name.

3. View the details of a specific ClusterObjectSet by running the following command:

   $ oc get clusterobjectset <clusterobjectset_name> -o yaml

   Shows deployment phases, resource status, and conditions.

4. Check the ClusterExtension status to see active revisions by running the following command:

   $ oc get clusterextension <extension_name> -o jsonpath='{.status.activeRevisions}{"\n"}'

   Shows the active revisions currently deployed.

Procedure

1. Create a ClusterExtension resource with deploymentConfig customizations:

   apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     name: my-operator
   spec:
     namespace: my-operator-ns
     config:
       configType: Inline
       inline:
         deploymentConfig:
           resources:
             requests:
               cpu: 100m
               memory: 128Mi
             limits:
               cpu: 500m
               memory: 512Mi
           nodeSelector:
             node-role.kubernetes.io/infra: ""
           tolerations:
           - key: node-role.kubernetes.io/infra
             operator: Exists
             effect: NoSchedule
     source:
       sourceType: Catalog
       catalog:
         packageName: my-operator
         version: 1.0.0

   where:

   resources:

   Specifies CPU and memory resource requests and limits for the Operator pod.

   nodeSelector:

   Specifies pod scheduling restrictions to infrastructure nodes.

   tolerations:

   Specifies pod tolerations that allow scheduling on nodes with the specified taint.

2. Apply the ClusterExtension resource:

   $ oc apply -f my-operator.yaml

3. Verify the installation:

   $ oc get clusterextension my-operator -o yaml

Procedure

1. If the installed cluster extension does not provide default cluster roles, manually create one or more roles:

   1. Consider the use cases for the set of roles described in "Common default cluster roles for users".

      For example, create one or more of the following ClusterRole object definitions, replacing <cluster_extension_api_group> and <cluster_extension_custom_resource> with the actual API group and resource names provided by the installed cluster extension:

      Example view-custom-resource.yaml file

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: view-custom-resource
      rules:
      - apiGroups:
        - <cluster_extension_api_group>
        resources:
        - <cluster_extension_custom_resources>
        verbs:
        - get
        - list
        - watch

      Example edit-custom-resource.yaml file

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: edit-custom-resource
      rules:
      - apiGroups:
        - <cluster_extension_api_group>
        resources:
        - <cluster_extension_custom_resources>
        verbs:
        - get
        - list
        - watch
        - create
        - update
        - patch
        - delete

      Example admin-custom-resource.yaml file

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: admin-custom-resource
      rules:
      - apiGroups:
        - <cluster_extension_api_group>
        resources:
        - <cluster_extension_custom_resources>
        verbs:
        - '*'

      Setting a wildcard (*) in the rules.verbs field allows all actions on the specified resources.

   2. Create the cluster roles by running the following command for any YAML files you created:

      $ oc create -f <filename>.yaml

2. Associate a cluster role to specific users or groups to grant them the necessary permissions for the resource by binding the cluster roles to individual user or group names:

   1. Create an object definition for either a cluster role binding to grant access across all namespaces or a role binding to grant access within a specific namespace:

      • The following example cluster role bindings grant read-only view access to the custom resource across all namespaces:

        Example ClusterRoleBinding object for a user

        apiVersion: rbac.authorization.k8s.io/v1
        kind: ClusterRoleBinding
        metadata:
          name: view-custom-resource-binding
        subjects:
        - kind: User
          name: <user_name>
        roleRef:
          kind: ClusterRole
          name: view-custom-resource
          apiGroup: rbac.authorization.k8s.io

        Example ClusterRoleBinding object for a user

        apiVersion: rbac.authorization.k8s.io/v1
        kind: ClusterRoleBinding
        metadata:
          name: view-custom-resource-binding
        subjects:
        - kind: Group
          name: <group_name>
        roleRef:
          kind: ClusterRole
          name: view-custom-resource
          apiGroup: rbac.authorization.k8s.io

      • The following role binding restricts edit permissions to a specific namespace:

        Example RoleBinding object for a user

        apiVersion: rbac.authorization.k8s.io/v1
        kind: RoleBinding
        metadata:
          name: edit-custom-resource-edit-binding
          namespace: <namespace>
        subjects:
        - kind: User
          name: <username>
        roleRef:
          kind: Role
          name: custom-resource-edit
          apiGroup: rbac.authorization.k8s.io

   2. Save your object definition to a YAML file.

   3. Create the object by running the following command:

      $ oc create -f <filename>.yaml

Procedure

1. Create an object definition for a cluster role that specifies the API groups and resources provided by the cluster extension and add an aggregation label to extend one or more existing default cluster roles:

   Example ClusterRole object with an aggregation label

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: view-custom-resource-aggregated
     labels:
       rbac.authorization.k8s.io/aggregate-to-view: "true"
   rules:
     - apiGroups:
         - <cluster_extension_api_group>
       resources:
         - <cluster_extension_custom_resource>
       verbs:
         - get
         - list
         - watch

   You can create similar ClusterRole objects for edit and admin with appropriate verbs, such as create, update, and delete. By using aggregation labels, the permissions for the custom resources are added to the default roles.

2. Save your object definition to a YAML file.

3. Create the object by running the following command:

   $ oc create -f <filename>.yaml

Procedure

1. Edit the custom resource (CR) of your Operator or extension as shown in the following example:

   Example CR

   apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     name: <clusterextension_name>
   spec:
     namespace: <installed_namespace>
     source:
       sourceType: Catalog
       catalog:
         packageName: <package_name>
         channels:
           - <channel_name>
         version: <version_or_version_range>
         upgradeConstraintPolicy: SelfCertified

   where:

   spec.namespace

   Specifies the namespace where you want the bundle installed, such as pipelines or my-extension. Extensions are still cluster-scoped and might contain resources that are installed in different namespaces.

   spec.source.catalog.channels

   Specifies channel names as an array, such as pipelines-1.14 or latest. This field is optional.

   spec.source.catalog.version

   Specifies the version or version range, such as 1.14.0, 1.14.x, or >=1.16, of the package you want to install or update. This field is optional.

   spec.source.catalog.upgradeConstraintPolicy

   Specifies the upgrade constraint policy. To force an update or rollback, set the field to SelfCertified. If unspecified, the default setting is CatalogProvided. The CatalogProvided setting only updates if the new version satisfies the upgrade constraints set by the package author. This field is optional.

2. Apply the changes to your Operator or extensions CR by running the following command:

   $ oc apply -f <extension_name>.yaml

Procedure

1. Edit the ClusterExtension object of the CRD:

   $ oc edit clusterextension <clusterextension_name>

2. Set the install.preflight.crdUpgradeSafety.enforcement field to None:

   Example ClusterExtension object

   apiVersion: olm.operatorframework.io/v1
   kind: ClusterExtension
   metadata:
     name: clusterextension-sample
   spec:
     namespace: default
     source:
       sourceType: "Catalog"
       catalog:
         packageName: argocd-operator
         version: 0.6.0
     install:
       preflight:
         crdUpgradeSafety:
           enforcement: None