Skip to content

Commit b50a77f

Browse files
GroceryBoyJrGroceryBoyJr
committed
CMP-2582: Update CO install documentation to include ROSA support
1 parent ba243ea commit b50a77f

File tree

3 files changed

+110
-2
lines changed

3 files changed

+110
-2
lines changed

‎modules/compliance-operator-hcp-install.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
:_mod-docs-content-type: PROCEDURE
66
[id="installing-compliance-operator-hcp_{context}"]
7-
= Installing the Compliance Operator on {hcp}
7+
= Installing the Compliance Operator on Hypershift {hcp}
88

99
The Compliance Operator can be installed in {hcp} using the OperatorHub by creating a `Subscription` file.
1010

‎modules/compliance-operator-rosa-installation.adoc

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * security/compliance_operator/co-management/compliance-operator-installation.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="installing-compliance-operator-rosa_{context}"]
7+
= Installing the Compliance Operator on ROSA hosted control planes (HCP)
8+
9+
As of the Compliance Operator 1.5.0 release, the Operator is tested against {product-rosa} using {hcp-capital}.
10+
11+
{product-rosa} {hcp-capital} clusters have restricted access to the control plane, which is managed by Red{nbsp}Hat. By default, the Compliance Operator will schedule to nodes within the `master` node pool, which is not available in {product-rosa} {hcp-capital} installations. This requires you to configure the `Subscription` object in a way that allows the Operator to schedule on available node pools. This step is necessary for a successful installation on {product-rosa} {hcp-capital} clusters.
12+
13+
.Prerequisites
14+
15+
* You must have `admin` privileges.
16+
17+
.Procedure
18+
19+
. Define a `Namespace` object:
20+
+
21+
.Example `namespace-object.yaml` file
22+
[source,yaml]
23+
----
24+
apiVersion: v1
25+
kind: Namespace
26+
metadata:
27+
labels:
28+
openshift.io/cluster-monitoring: "true"
29+
pod-security.kubernetes.io/enforce: privileged <1>
30+
name: openshift-compliance
31+
----
32+
<1> In {product-title} {product-version}, the pod security label must be set to `privileged` at the namespace level.
33+
34+
. Create the `Namespace` object by running the following command:
35+
+
36+
[source,terminal]
37+
----
38+
$ oc create -f namespace-object.yaml
39+
----
40+
41+
. Define an `OperatorGroup` object:
42+
+
43+
.Example `operator-group-object.yaml` file
44+
[source,yaml]
45+
----
46+
apiVersion: operators.coreos.com/v1
47+
kind: OperatorGroup
48+
metadata:
49+
name: compliance-operator
50+
namespace: openshift-compliance
51+
spec:
52+
targetNamespaces:
53+
- openshift-compliance
54+
----
55+
56+
. Create the `OperatorGroup` object by running the following command:
57+
+
58+
[source,terminal]
59+
----
60+
$ oc create -f operator-group-object.yaml
61+
----
62+
63+
. Define a `Subscription` object:
64+
+
65+
.Example `subscription-object.yaml` file
66+
[source,yaml]
67+
----
68+
apiVersion: operators.coreos.com/v1alpha1
69+
kind: Subscription
70+
metadata:
71+
name: compliance-operator-sub
72+
namespace: openshift-compliance
73+
spec:
74+
channel: "stable"
75+
installPlanApproval: Automatic
76+
name: compliance-operator
77+
source: redhat-operators
78+
sourceNamespace: openshift-marketplace
79+
config:
80+
nodeSelector:
81+
node-role.kubernetes.io/worker: "" <1>
82+
----
83+
<1> Update the Operator deployment to deploy on `worker` nodes.
84+
85+
. Create the `Subscription` object by running the following command:
86+
+
87+
[source,terminal]
88+
----
89+
$ oc create -f subscription-object.yaml
90+
----
91+
92+
.Verification
93+
94+
. Verify that the installation succeeded by running the following command to inspect the cluster service version (CSV) file:
95+
+
96+
[source,terminal]
97+
----
98+
$ oc get csv -n openshift-compliance
99+
----
100+
101+
. Verify that the Compliance Operator is up and running by using the following command:
102+
+
103+
[source,terminal]
104+
----
105+
$ oc get deploy -n openshift-compliance
106+
----

‎security/compliance_operator/co-management/compliance-operator-installation.adoc

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ Before you can use the Compliance Operator, you must ensure it is deployed in th
1010

1111
[IMPORTANT]
1212
====
13-
The Compliance Operator might report incorrect results on managed platforms, such as OpenShift Dedicated, Red Hat OpenShift Service on AWS, and Microsoft Azure Red Hat OpenShift. For more information, see the link:https://access.redhat.com/solutions/6983418[Red Hat Knowledgebase Solution #6983418].
13+
The Compliance Operator might report incorrect results on managed platforms, such as OpenShift Dedicated, Red{nbsp}Hat OpenShift Service on AWS Classic, and Microsoft Azure Red{nbsp}Hat OpenShift. For more information, see the Knowledgebase article link:https://access.redhat.com/solutions/6983418[Compliance Operator reports incorrect results on Managed Services].
1414
====
1515

1616
include::modules/compliance-operator-console-installation.adoc[leveloffset=+1]
@@ -24,6 +24,8 @@ You can create a custom SCC for the Compliance Operator scanner pod service acco
2424

2525
include::modules/compliance-operator-cli-installation.adoc[leveloffset=+1]
2626

27+
include::modules/compliance-operator-rosa-installation.adoc[leveloffset=+1]
28+
2729
[IMPORTANT]
2830
====
2931
If the `restricted` Security Context Constraints (SCC) have been modified to contain the `system:authenticated` group or has added `requiredDropCapabilities`, the Compliance Operator may not function properly due to permissions issues.

0 commit comments

Comments
 (0)