1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OSDOCS#12884[4.18][OLMv1]Create RBAC to manage and install ce

This commit is contained in:
Michael Ryan Peter
2025-01-24 16:48:57 -05:00
committed by openshift-cherrypick-robot
parent c5cbaf3ce3
commit b8491a1264
12 changed files with 1231 additions and 181 deletions

View File

@@ -8,7 +8,7 @@ toc::[]
After a catalog has been added to your cluster, you have access to the versions, patches, and over-the-air updates of the extensions and Operators that are published to the catalog. After a catalog has been added to your cluster, you have access to the versions, patches, and over-the-air updates of the extensions and Operators that are published to the catalog.
You can manage extensions declaratively from the CLI using custom resources (CRs). You can use custom resources (CRs) to manage extensions declaratively from the CLI.
include::modules/olmv1-supported-extensions.adoc[leveloffset=+1] include::modules/olmv1-supported-extensions.adoc[leveloffset=+1]
@@ -18,7 +18,14 @@ include::modules/olmv1-supported-extensions.adoc[leveloffset=+1]
include::modules/olmv1-finding-operators-to-install.adoc[leveloffset=+1] include::modules/olmv1-finding-operators-to-install.adoc[leveloffset=+1]
include::modules/olmv1-catalog-queries.adoc[leveloffset=+2] include::modules/olmv1-catalog-queries.adoc[leveloffset=+2]
include::modules/olmv1-creating-a-service-account.adoc[leveloffset=+1] include::modules/olmv1-cluster-extension-permissions.adoc[leveloffset=+1]
include::modules/olmv1-creating-a-namespace.adoc[leveloffset=+2]
include::modules/olmv1-creating-a-service-account.adoc[leveloffset=+2]
include::modules/olmv1-downloading-bundle-manifests.adoc[leveloffset=+2]
include::modules/olmv1-required-rbac-to-install-and-manage-extension-resources.adoc[leveloffset=+2]
include::modules/olmv1-creating-a-cluster-role.adoc[leveloffset=+2]
include::modules/olmv1-example-pipelines-operator-cluster-role.adoc[leveloffset=+2]
include::modules/olmv1-creating-a-cluster-role-binding.adoc[leveloffset=+2]
include::modules/olmv1-installing-an-operator.adoc[leveloffset=+1] include::modules/olmv1-installing-an-operator.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]

View File

@@ -0,0 +1,20 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: CONCEPT
[id="olmv1-cluster-extension-permissions_{context}"]
= Cluster extension permissions
In {olmv0-first}, a single service account with cluster administrator privileges manages all cluster extensions.
{olmv1} is designed to be more secure than {olmv0} by default. {olmv1} manages a cluster extension by using the service account specified in an extension's custom resource (CR). Cluster administrators can create a service account for each cluster extension. As a result, administrators can follow the principle of least privilege and assign only the role-based access controls (RBAC) to install and manage that extension.
You must add each permission to either a cluster role or role. Then you must bind the cluster role or role to the service account with a cluster role binding or role binding.
You can scope the RBAC to either the cluster or to a namespace. Use cluster roles and cluster role bindings to scope permissions to the cluster. Use roles and role bindings to scope permissions to a namespace. Whether you scope the permissions to the cluster or to a namespace depends on the design of the extension you want to install and manage.
include::snippets/olmv1-manual-rbac-scoping-admonition.adoc[]
If a new version of an installed extension requires additional permissions, {olmv1} halts the update process until a cluster administrator grants those permissions.

View File

@@ -0,0 +1,65 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: PROCEDURE
[id="olmv1-creating-a-cluster-rol-binding_{context}"]
= Creating a cluster role binding for an extension
After you have created a service account and cluster role, you must bind the cluster role to the service account with a cluster role binding manifest.
.Prerequisites
* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
* You have created and applied the following resources for the extension you want to install:
** Namespace
** Service account
** Cluster role
.Procedure
. Create a cluster role binding to bind the cluster role to the service account, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: <extension>-installer-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: <extension>-installer-clusterrole
subjects:
- kind: ServiceAccount
name: <extension>-installer
namespace: <namespace>
----
+
.Example `pipelines-cluster-role-binding.yaml` file
[%collapsible]
====
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: pipelines-installer-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: pipelines-installer-clusterrole
subjects:
- kind: ServiceAccount
name: pipelines-installer
namespace: pipelines
----
====
. Apply the cluster role binding by running the following command:
+
[source,terminal]
----
$ oc apply -f pipelines-cluster-role-binding.yaml
----

View File

@@ -0,0 +1,346 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: PROCEDURE
[id="olmv1-creating-a-cluster-role_{context}"]
= Creating a cluster role for an extension
You must review the `install.spec.clusterpermissions` stanza of the cluster service version (CSV) and the manifests of an extension carefully to define the required role-based access controls (RBAC) of the extension that you want to install. You must create a cluster role by copying the required RBAC from the CSV to the new manifest.
[TIP]
====
If you want to test the process for installing and updating an extension in {olmv1}, you can use the following cluster role to grant cluster administrator permissions. This manifest is for testing purposes only. It should not be used in production clusters.
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: <extension>-installer-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
----
====
The following procedure uses the `openshift-pipelines-operator-rh.clusterserviceversion.yaml` file of the {pipelines-title} Operator as an example. The examples include excerpts of the RBAC required to install and manage the {pipelines-shortname} Operator. For a complete manifest, see "Example cluster role for the {pipelines-title} Operator".
include::snippets/olmv1-manual-rbac-scoping-admonition.adoc[]
.Prerequisites
* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
* You have downloaded the manifests in the image reference of the extension that you want to install.
.Procedure
. Create a new cluster role manifest, similar to the following example:
+
.Example `<extension>-cluster-role.yaml` file
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: <extension>-installer-clusterrole
----
. Edit your cluster role manifest to include permission to update finalizers on the extension, similar to the following example:
+
.Example <extension>-cluster-role.yaml
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
- apiGroups:
- olm.operatorframework.io
resources:
- clusterextensions/finalizers
verbs:
- update
# Scoped to the name of the ClusterExtension
resourceNames:
- <metadata_name> # <1>
----
<1> Specifies the value from the `metadata.name` field from the custom resource (CR) of the extension.
. Search for the `clusterrole` and `clusterrolebindings` values in the `rules.resources` field in the extension's CSV file.
** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
+
.Example cluster role manifest
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
# ...
# ClusterRoles and ClusterRoleBindings for the controllers of the extension
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterroles
verbs:
- create # <1>
- list
- watch
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterroles
verbs:
- get
- update
- patch
- delete
resourceNames: # <2>
- "*"
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterrolebindings
verbs:
- create
- list
- watch
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterrolebindings
verbs:
- get
- update
- patch
- delete
resourceNames:
- "*"
# ...
----
<1> You cannot scope `create`, `list`, and `watch` permissions to specific resource names (the `resourceNames` field). You must scope these permissions to their resources (the `resources` field).
<2> Some resource names are generated by using the following format: `<package_name>.<hash>`. After you install the extension, look up the resource names for the cluster roles and cluster role bindings for the controller of the extension. Replace the wildcard characters in this example with the generated names and follow the principle of least privilege.
. Search for the `customresourcedefinitions` value in the `rules.resources` field in the extension's CSV file.
** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
# ...
# Custom resource definitions of the extension
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- create
- list
- watch
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- get
- update
- patch
- delete
resourceNames:
- manualapprovalgates.operator.tekton.dev
- openshiftpipelinesascodes.operator.tekton.dev
- tektonaddons.operator.tekton.dev
- tektonchains.operator.tekton.dev
- tektonconfigs.operator.tekton.dev
- tektonhubs.operator.tekton.dev
- tektoninstallersets.operator.tekton.dev
- tektonpipelines.operator.tekton.dev
- tektonresults.operator.tekton.dev
- tektontriggers.operator.tekton.dev
# ...
----
. Search the CSV file for stanzas with the `permissions` and `clusterPermissions` values in the `rules.resources` spec.
** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
# ...
# Excerpt from install.spec.clusterPermissions
- apiGroups:
- ''
resources:
- nodes
- pods
- services
- endpoints
- persistentvolumeclaims
- events
- configmaps
- secrets
- pods/log
- limitranges
verbs:
- create
- list
- watch
- delete
- deletecollection
- patch
- get
- update
- apiGroups:
- extensions
- apps
resources:
- ingresses
- ingresses/status
verbs:
- create
- list
- watch
- delete
- patch
- get
- update
# ...
----
. Search the CSV file for resources under the `install.spec.deployments` stanza.
** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
# ...
# Excerpt from install.spec.deployments
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- list
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- get
- update
- patch
- delete
# scoped to the extension controller deployment name
resourceNames:
- openshift-pipelines-operator
- tekton-operator-webhook
# ...
----
. Search for the `services` and `configmaps` values in the `rules.resources` field in the extension's CSV file.
** Copy the API groups, resources, verbs, and resource names to your manifest, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
# ...
# Services
- apiGroups:
- ""
resources:
- services
verbs:
- create
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- update
- patch
- delete
# scoped to the service name
resourceNames:
- openshift-pipelines-operator-monitor
- tekton-operator
- tekton-operator-webhook
# configmaps
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- ""
resources:
- configmaps
verbs:
- get
- list
- watch
- update
- patch
- delete
# scoped to the configmap name
resourceNames:
- config-logging
- tekton-config-defaults
- tekton-config-observability
- tekton-operator-controller-config-leader-election
- tekton-operator-info
- tekton-operator-webhook-config-leader-election
- apiGroups:
- operator.tekton.dev
resources:
- tekton-config-read-role
- tekton-result-read-role
verbs:
- get
- watch
- list
----
. Add the cluster role manifest to the cluster by running the following command:
+
[source,terminal]
----
$ oc apply -f <extension>-installer-clusterrole.yaml
----
+
.Example command
[source,terminal]
----
$ oc apply -f pipelines-installer-clusterrole.yaml
----

View File

@@ -0,0 +1,23 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: PROCEDURE
[id="olmv1-creating-a-namespace_{context}"]
= Creating a namespace
Before you create a service account to install and manage your cluster extension, you must create a namespace.
.Prerequisites
* Access to an {product-title} cluster using an account with `cluster-admin` permissions.
.Procedure
* Create a new namespace for the service account of the extension that you want to install by running the following command:
+
[source,terminal]
----
$ oc adm new-project <new_namespace>
----

View File

@@ -5,14 +5,9 @@
:_mod-docs-content-type: PROCEDURE :_mod-docs-content-type: PROCEDURE
[id="olmv1-creating-a-service-account_{context}"] [id="olmv1-creating-a-service-account_{context}"]
= Creating a service account to manage cluster extensions = Creating a service account for an extension
Unlike {olmv0-first}, {olmv1} does not have permissions to install, update, and manage cluster extensions. Cluster administrators must create a service account and assign the role-based access controls (RBAC) required to install, update, and manage cluster extensions. You must create a service account to install, manage, and update a cluster extension.
[IMPORTANT]
====
include::snippets/olmv1-known-issue-service-accounts.adoc[]
====
.Prerequisites .Prerequisites
@@ -50,89 +45,3 @@ metadata:
---- ----
$ oc apply -f extension-service-account.yaml $ oc apply -f extension-service-account.yaml
---- ----
. Create a cluster role and assign RBAC, similar to the following example:
+
[WARNING]
====
The following cluster role does not follow the principle of least privilege. This cluster role is intended for testing purposes only. Do not use it on production clusters.
====
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: <extension>-installer-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
----
+
.Example `pipelines-cluster-role.yaml` file
[%collapsible]
====
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
----
====
. Add the cluster role to the cluster by running the following command:
+
[source,terminal]
----
$ oc apply -f pipelines-role.yaml
----
. Bind the permissions granted by the cluster role to the service account by creating a cluster role binding, similar to the following example:
+
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: <extension>-installer-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: <extension>-installer-clusterrole
subjects:
- kind: ServiceAccount
name: <extension>-installer
namespace: <namespace>
----
+
.Example `pipelines-cluster-role-binding.yaml` file
[%collapsible]
====
[source,yaml]
----
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: pipelines-installer-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: pipelines-installer-clusterrole
subjects:
- kind: ServiceAccount
name: pipelines-installer
namespace: pipelines
----
====
. Apply the cluster role binding by running the following command:
+
[source,terminal]
----
$ oc apply -f pipelines-cluster-role-binding.yaml
----

View File

@@ -0,0 +1,151 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: PROCEDURE
[id="olmv1-downloading-bundle-manifests_{context}"]
= Downloading the bundle manifests of an extension
Use the `opm` CLI tool to download the bundle manifests of the extension that you want to install. Use the CLI tool or text editor of your choice to view the manifests and find the required permissions to install and manage the extension.
.Prerequisites
* You have access to an {product-title} cluster using an account with `cluster-admin` permissions.
* You have decided which extension you want to install.
* You have installed the `opm` CLI tool.
.Procedure
. Inspect the available versions and images of the extension you want to install by running the following command:
+
[source,terminal]
----
$ opm render <registry_url>:<tag_or_version> | \
jq -cs '.[] | select( .schema == "olm.bundle" ) | \
select( .package == "<extension_name>") | \
{"name":.name, "image":.image}'
----
+
.Example command
[%collapsible]
====
[source,terminal,subs="attributes"]
----
$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} | \
jq -cs '.[] | select( .schema == "olm.bundle" ) | \
select( .package == "openshift-pipelines-operator-rh") | \
{"name":.name, "image":.image}'
----
====
+
.Example output
[%collapsible]
====
[source,text]
----
{"name":"openshift-pipelines-operator-rh.v1.14.3","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:3f64b29f6903981470d0917b2557f49d84067bccdba0544bfe874ec4412f45b0"}
{"name":"openshift-pipelines-operator-rh.v1.14.4","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"}
{"name":"openshift-pipelines-operator-rh.v1.14.5","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838"}
{"name":"openshift-pipelines-operator-rh.v1.15.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:22be152950501a933fe6e1df0e663c8056ca910a89dab3ea801c3bb2dc2bf1e6"}
{"name":"openshift-pipelines-operator-rh.v1.15.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:64afb32e3640bb5968904b3d1a317e9dfb307970f6fda0243e2018417207fd75"}
{"name":"openshift-pipelines-operator-rh.v1.15.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd"}
{"name":"openshift-pipelines-operator-rh.v1.16.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:a46b7990c0ad07dae78f43334c9bd5e6cba7b50ca60d3f880099b71e77bed214"}
{"name":"openshift-pipelines-operator-rh.v1.16.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:29f27245e93b3f605647993884751c490c4a44070d3857a878d2aee87d43f85b"}
{"name":"openshift-pipelines-operator-rh.v1.16.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2037004666526c90329f4791f14cb6cc06e8775cb84ba107a24cc4c2cf944649"}
{"name":"openshift-pipelines-operator-rh.v1.17.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:d75065e999826d38408049aa1fde674cd1e45e384bfdc96523f6bad58a0e0dbc"}
----
====
. Make a directory to extract the image of the bundle that you want to install by running the following command:
+
[source,terminal]
----
$ mkdir <new_dir>
----
. Change into the directory by running the following command:
+
[source,terminal]
----
$ cd <new_dir>
----
. Find the image reference of the version that you want to install and run the following command:
+
[source,terminal]
----
$ oc image extract <full_path_to_registry_image>@sha256:<sha>
----
+
.Example command
[source,terminal]
----
$ oc image extract registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
----
. Change into the `manifests` directory by running the following command:
+
[source,terminal]
----
$ cd manifests
----
. 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.
+
[source,terminal]
----
$ tree
----
+
.Example output
[%collapsible]
====
[source,text]
----
.
├── 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
----
====
.Next steps
* View the contents of the `install.spec.clusterpermissions` stanza of cluster service version (CSV) file in the `manifests` directory using your preferred CLI tool or text editor. The following examples reference the `openshift-pipelines-operator-rh.clusterserviceversion.yaml` file of the {pipelines-title} Operator.
* Keep this file open as a reference while assigning permissions to the cluster role file in the following procedure.

View File

@@ -0,0 +1,15 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: REFERENCE
[id="olmv1-example-cluster-role-pipelines_{context}"]
= Example cluster role for the {pipelines-title} Operator
See the following example for a complete cluster role manifest for the {pipelines-shortname} Operator.
[source,yaml]
----
include::snippets/example-pipelines-installer-clusterrole.yaml[]
----

View File

@@ -7,98 +7,14 @@
[id="olmv1-installing-an-operator_{context}"] [id="olmv1-installing-an-operator_{context}"]
= Installing a cluster extension from a catalog = Installing a cluster extension from a catalog
You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. {olmv1-first} supports installing cluster extensions, including {olmv0} Operators via the `registry+v1` bundle format, that are scoped to the cluster. For more information, see _Supported extensions_. You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. {olmv1-first} supports installing cluster extensions, including {olmv0} Operators in the `registry+v1` bundle format, that are scoped to the cluster. For more information, see _Supported extensions_.
.Prerequisites .Prerequisites
* You have installed the `jq` CLI tool. * You have created a service account and assigned enough role-based access controls (RBAC) to install, update, and manage the extension that you want to install. For more information, see "Cluster extension permissions".
* You have installed the `opm` CLI tool.
* You have created a service account and assigned enough role-based access controls (RBAC) to install, update, and manage the extension you want to install. For more information, see "Creating a service account to manage cluster extensions".
.Procedure .Procedure
. Inspect a package for channel and version information from a local copy of your catalog file by completing the following steps:
.. Get a list of channels from a selected package by running the following command:
+
[source,terminal]
----
$ opm render <catalog_registry_url>:<tag> \
| jq -s '.[] | select( .schema == "olm.channel" ) \
| select( .package == "<package_name>") \
| .name'
----
+
.Example command
[%collapsible]
====
[source,terminal,subs=attributes+]
----
$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
| jq -s '.[] | select( .schema == "olm.channel" ) \
| select( .package == "openshift-pipelines-operator-rh") \
| .name'
----
====
+
.Example output
[%collapsible]
====
[source,text]
----
"latest"
"pipelines-1.14"
"pipelines-1.15"
"pipelines-1.16"
----
====
.. Get a list of the versions published in a channel by running the following command:
+
[source,terminal]
----
$ opm render <catalog_registry_url>:<tag> \
| jq -s '.[] | select( .package == "<package_name>" ) \
| select( .schema == "olm.channel" ) \
| select( .name == "<channel_name>" ) | .entries \
| .[] | .name'
----
+
.Example command
[%collapsible]
====
[source,terminal,subs=attributes+]
----
$ opm render registry.redhat.io/redhat/redhat-operator-index:v{product-version} \
| jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) \
| select( .schema == "olm.channel" ) | select( .name == "latest" ) \
| .entries | .[] | .name'
----
====
+
.Example output
[%collapsible]
====
[source,text]
----
"openshift-pipelines-operator-rh.v1.14.3"
"openshift-pipelines-operator-rh.v1.14.4"
"openshift-pipelines-operator-rh.v1.14.5"
"openshift-pipelines-operator-rh.v1.15.0"
"openshift-pipelines-operator-rh.v1.15.1"
"openshift-pipelines-operator-rh.v1.15.2"
"openshift-pipelines-operator-rh.v1.16.0"
"openshift-pipelines-operator-rh.v1.16.1"
----
====
. If you want to install your extension into a new namespace, run the following command:
+
[source,terminal]
----
$ oc adm new-project <new_namespace>
----
. Create a CR, similar to the following example: . Create a CR, similar to the following example:
+ +
.Example `pipelines-operator.yaml` CR .Example `pipelines-operator.yaml` CR

View File

@@ -0,0 +1,37 @@
// Module included in the following assemblies:
//
// * extensions/ce/managing-ce.adoc
:_mod-docs-content-type: REFERENCE
[id="olmv1-required-rbac-to-install-and-manage-extension-resources_{context}"]
= Required permissions to install and manage a cluster extension
You must inspect the manifests included in the bundle image of a cluster extension to assign the necessary permissions. The service account requires enough role-based access controls (RBAC) to create and manage the following resources.
[IMPORTANT]
====
Follow the principle of least privilege and scope permissions to specific resource names with the least RBAC required to run.
====
Admission plugins:: Because {product-title} clusters use the `OwnerReferencesPermissionEnforcement` admission plugin, cluster extensions must have permissions to update the `blockOwnerDeletion` and `ownerReferences` finalizers.
Cluster role and cluster role bindings for the controllers of the extension:: You must define RBAC so that the installation service account can create and manage cluster roles and cluster role bindings for the extension controllers.
Cluster service version (CSV):: You must define RBAC for the resources defined in the CSV of the cluster extension.
Cluster-scoped bundle resources:: You must define RBAC to create and manage any cluster-scoped resources included in the bundle. If the cluster-scoped resources matches another resource type, such as a `ClusterRole`, you can add the resource to the pre-existing rule under the `resources` or `resourceNames` field.
Custom resource definitions (CRDs):: You must define RBAC so that the installation service account can create and manage the CRDs for the extension. Also, you must grant the service account for the controller of the extension the RBAC to manage its CRDs.
Deployments:: You must define RBAC for the installation service account to create and manage the deployments needed by the extension controller, such as services and config maps.
Extension permissions:: You must include RBAC for the permissions and cluster permissions defined in the CSV. The installation service account needs the ability to grant these permissions to the extension controller, which needs these permissions to run.
Namespace-scoped bundle resources:: You must define RBAC for any namespace-scoped bundle resources. The installation service account requires permission to create and manage resources, such as config maps or services.
Roles and role bindings:: You must define RBAC for any roles or role bindings defined in the CSV. The installation service account needs permission to create and manage those roles and role bindings.
// I am deleting the secrets section because I think it covered under the "extension permissions" term. Please let me know if I should put it back and if you have a suggestion for the defintion.
Service accounts:: You must define RBAC so that the installation service account can create and manage the service accounts for the extension controllers.

View File

@@ -0,0 +1,550 @@
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pipelines-installer-clusterrole
rules:
- apiGroups:
- olm.operatorframework.io
resources:
- clusterextensions/finalizers
verbs:
- update
# Scoped to the name of the ClusterExtension
resourceNames:
- pipes # the value from <metadata.name> from the extension's custom resource (CR)
# ClusterRoles and ClusterRoleBindings for the controllers of the extension
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterroles
verbs:
- create
- list
- watch
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterroles
verbs:
- get
- update
- patch
- delete
resourceNames:
- "*"
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterrolebindings
verbs:
- create
- list
- watch
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterrolebindings
verbs:
- get
- update
- patch
- delete
resourceNames:
- "*"
# Extension's custom resource definitions
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- create
- list
- watch
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- get
- update
- patch
- delete
resourceNames:
- manualapprovalgates.operator.tekton.dev
- openshiftpipelinesascodes.operator.tekton.dev
- tektonaddons.operator.tekton.dev
- tektonchains.operator.tekton.dev
- tektonconfigs.operator.tekton.dev
- tektonhubs.operator.tekton.dev
- tektoninstallersets.operator.tekton.dev
- tektonpipelines.operator.tekton.dev
- tektonresults.operator.tekton.dev
- tektontriggers.operator.tekton.dev
- apiGroups:
- ''
resources:
- nodes
- pods
- services
- endpoints
- persistentvolumeclaims
- events
- configmaps
- secrets
- pods/log
- limitranges
verbs:
- create
- list
- watch
- delete
- deletecollection
- patch
- get
- update
- apiGroups:
- extensions
- apps
resources:
- ingresses
- ingresses/status
verbs:
- create
- list
- watch
- delete
- patch
- get
- update
- apiGroups:
- ''
resources:
- namespaces
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- apps
resources:
- deployments
- daemonsets
- replicasets
- statefulsets
- deployments/finalizers
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- monitoring.coreos.com
resources:
- servicemonitors
verbs:
- get
- create
- delete
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterroles
- roles
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- bind
- escalate
- apiGroups:
- ''
resources:
- serviceaccounts
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- impersonate
- apiGroups:
- rbac.authorization.k8s.io
resources:
- clusterrolebindings
- rolebindings
verbs:
- get
- update
- delete
- patch
- create
- list
- watch
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
- customresourcedefinitions/status
verbs:
- get
- create
- update
- delete
- list
- patch
- watch
- apiGroups:
- admissionregistration.k8s.io
resources:
- mutatingwebhookconfigurations
- validatingwebhookconfigurations
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- build.knative.dev
resources:
- builds
- buildtemplates
- clusterbuildtemplates
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- extensions
resources:
- deployments
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- extensions
resources:
- deployments/finalizers
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- operator.tekton.dev
resources:
- '*'
- tektonaddons
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- tekton.dev
- triggers.tekton.dev
- operator.tekton.dev
- pipelinesascode.tekton.dev
resources:
- '*'
verbs:
- add
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- dashboard.tekton.dev
resources:
- '*'
- tektonaddons
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- security.openshift.io
resources:
- securitycontextconstraints
verbs:
- use
- get
- list
- create
- update
- delete
- apiGroups:
- events.k8s.io
resources:
- events
verbs:
- create
- apiGroups:
- route.openshift.io
resources:
- routes
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- coordination.k8s.io
resources:
- leases
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
- apiGroups:
- console.openshift.io
resources:
- consoleyamlsamples
- consoleclidownloads
- consolequickstarts
- consolelinks
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- delete
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- policy
resources:
- poddisruptionbudgets
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- monitoring.coreos.com
resources:
- servicemonitors
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- batch
resources:
- jobs
- cronjobs
verbs:
- delete
- deletecollection
- create
- patch
- get
- list
- update
- watch
- apiGroups:
- ''
resources:
- namespaces/finalizers
verbs:
- update
- apiGroups:
- resolution.tekton.dev
resources:
- resolutionrequests
- resolutionrequests/status
verbs:
- get
- list
- watch
- create
- delete
- update
- patch
- apiGroups:
- console.openshift.io
resources:
- consoleplugins
verbs:
- get
- list
- watch
- create
- delete
- update
- patch
# Deployments specified in install.spec.deployments
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- list
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- get
- update
- patch
- delete
# scoped to the extension controller deployment name
resourceNames:
- openshift-pipelines-operator
- tekton-operator-webhook
# Service accounts in the CSV
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- list
- watch
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- get
- update
- patch
- delete
# scoped to the extension controller's deployment service account
resourceNames:
- openshift-pipelines-operator
# Services
- apiGroups:
- ""
resources:
- services
verbs:
- create
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- update
- patch
- delete
# scoped to the service name
resourceNames:
- openshift-pipelines-operator-monitor
- tekton-operator
- tekton-operator-webhook
# configmaps
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- ""
resources:
- configmaps
verbs:
- get
- list
- watch
- update
- patch
- delete
# scoped to the configmap name
resourceNames:
- config-logging
- tekton-config-defaults
- tekton-config-observability
- tekton-operator-controller-config-leader-election
- tekton-operator-info
- tekton-operator-webhook-config-leader-election
- apiGroups:
- operator.tekton.dev
resources:
- tekton-config-read-role
- tekton-result-read-role
verbs:
- get
- watch
- list
---

View File

@@ -0,0 +1,11 @@
// Text snippet included in the following modules:
//
// * modules/olmv1-cluster-extension-permissions.adoc
// * modules/olmv1-creating-a-cluster-role.adoc
:_mod-docs-content-type: SNIPPET
[IMPORTANT]
====
To simply the following procedure and improve readability, the following example manifest uses permissions that are scoped to the cluster. You can further restrict some of the permissions by scoping them to the namespace of the extension instead of the cluster.
====