You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
= Verifying the signature verification configuration
8
8
9
+
[role="_abstract"]
9
10
After you apply the machine configs to the cluster, the Machine Config Controller detects the new `MachineConfig` object and generates a new `rendered-worker-<hash>` version.
10
11
11
12
.Prerequisites
@@ -20,7 +21,7 @@ After you apply the machine configs to the cluster, the Machine Config Controlle
20
21
$ oc describe machineconfigpool/worker
21
22
----
22
23
+
23
-
.Example output of initial worker monitoring
24
+
**Example output of initial worker monitoring**
24
25
+
25
26
[source,terminal]
26
27
----
@@ -126,7 +127,7 @@ Events: <none>
126
127
$ oc describe machineconfigpool/worker
127
128
----
128
129
+
129
-
.Example output after the worker is updated
130
+
**Example output after the worker is updated**
130
131
+
131
132
[source,terminal]
132
133
----
@@ -183,7 +184,7 @@ The `Observed Generation` parameter shows an increased count based on the genera
= Enabling signature verification for Red Hat Container Registries
8
8
9
+
[role="_abstract"]
9
10
Enabling container signature validation for Red Hat Container Registries requires writing a signature verification policy file specifying the keys to verify images from these registries. For RHEL8 nodes, the registries are already defined in `/etc/containers/registries.d` by default.
10
11
11
-
.Procedure
12
-
13
-
. Create a Butane config file, `51-worker-rh-registry-trust.bu`, containing the necessary configuration for the worker nodes.
12
+
.Prerequisites
13
+
* You have access to the cluster as a user with the `cluster-admin` role.
14
14
+
15
15
[NOTE]
16
16
====
17
17
include::snippets/butane-version.adoc[]
18
18
====
19
+
20
+
.Procedure
21
+
22
+
. Create a Butane config file, `51-worker-rh-registry-trust.bu`, containing the necessary configuration for the worker nodes:
Review the output to confirm that the new `51-worker-rh-registry-trust` machine config is listed and a new `rendered-worker` machine config has been created.
117
122
118
123
.. Check that the worker machine config pool is updating with the new machine config:
119
124
+
@@ -127,9 +132,10 @@ $ oc get mcp
127
132
----
128
133
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
<1> When the `UPDATING` field is `True`, the machine config pool is updating with the new machine config. When the field becomes `False`, the worker machine config pool has rolled out to the new machine config.
137
+
+
138
+
When the `UPDATING` field is `True`, the machine config pool is updating with the new machine config. When the field becomes `False`, the worker machine config pool has rolled out to the new machine config.
133
139
134
140
. If your cluster uses any RHEL7 worker nodes, when the worker machine config pool is updated, create YAML files on those nodes in the `/etc/containers/registries.d` directory, which specify the location of the detached signatures for a given registry server. The following example works only for images hosted in `registry.access.redhat.com` and `registry.redhat.io`.
= Using skopeo to verify signatures of Red Hat container images
8
8
9
-
You can verify the signatures for container images included in an {product-title} release image by pulling those signatures from link:https://mirror.openshift.com/pub/openshift-v4/signatures/openshift-release-dev/ocp-release/[OCP release mirror site]. Because the signatures on the mirror site are not in a format readily understood by Podman or CRI-O, you can use the `skopeo standalone-verify` command to verify that the your release images are signed by Red Hat.
9
+
[role="_abstract"]
10
+
You can verify the signatures for container images included in an {product-title} release image by pulling those signatures from the OCP release mirror site. Because the signatures on the mirror site are not in a format readily understood by Podman or CRI-O, you can use the `skopeo standalone-verify` command to verify that your release images are signed by Red Hat.
10
11
11
12
.Prerequisites
12
13
@@ -18,11 +19,12 @@ You can verify the signatures for container images included in an {product-title
18
19
+
19
20
[source,terminal]
20
21
----
21
-
$ oc adm release info <release_version> \ <1>
22
+
$ oc adm release info <release_version>
22
23
----
23
-
<1> Substitute <release_version> with your release number, for example, `4.14.3`.
24
24
+
25
-
.Example output snippet
25
+
Substitute `<release_version>` with your release number, for example, `4.14.3`.
<1> Replace `<sha_from_version>` with SHA value from the full link to the mirror site that matches the SHA of your release. For example, the link to the signature for the 4.12.23 release is `https://mirror.openshift.com/pub/openshift-v4/signatures/openshift-release-dev/ocp-release/sha256=e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55/signature-1`, and the SHA value is `e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55`.
49
+
+
50
+
Replace `<sha_from_version>` with the SHA value from the full link to the mirror site that matches the SHA of your release. For example, the link to the signature for the 4.12.23 release is `https://mirror.openshift.com/pub/openshift-v4/signatures/openshift-release-dev/ocp-release/sha256=e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55/signature-1`, and the SHA value is `e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55`.
48
51
49
52
. Get the manifest for the release image by running the following command:
<1> Replace `<quay_link_to_release>` with the output of the `oc adm release info` command. For example, `quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55`.
58
+
+
59
+
Replace `<quay_link_to_release>` with the output of the `oc adm release info` command. For example, `quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55`.
56
60
57
61
. Use skopeo to verify the signature:
58
62
+
@@ -66,9 +70,9 @@ where:
66
70
`<release_number>`:: Specifies the release number, for example `4.14.3`.
67
71
`<arch>`:: Specifies the architecture, for example `x86_64`.
68
72
+
69
-
.Example output
73
+
**Example output**
74
+
+
70
75
[source,terminal]
71
76
----
72
77
Signature verified using fingerprint 567E347AD0044ADE55BA8A5F199E2F91FD431D51, digest sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55
= Understanding the verification of container images lacking verifiable signatures
8
8
9
+
[role="_abstract"]
9
10
Each {product-title} release image is immutable and signed with a Red Hat production key. During an {product-title} update or installation, a release image might deploy container images that do not have verifiable signatures. Each signed release image digest is immutable. Each reference in the release image is to the immutable digest of another image, so the contents can be trusted transitively. In other words, the signature on the release image validates all release contents.
10
11
11
12
For example, the image references lacking a verifiable signature are contained in the signed {product-title} release image:
12
13
13
14
.Example release info output
14
15
[source,terminal]
15
16
----
16
-
$ oc adm release info quay.io/openshift-release-dev/ocp-release@sha256:2309578b68c5666dad62aed696f1f9d778ae1a089ee461060ba7b9514b7ca417 -o pullspec <1>
<2> Container image lacking a verifiable signature included in the release.
21
+
The first line displays the signed release image SHA. The subsequent lines display the container images lacking a verifiable signature that are securely included in the release.
To uninstall the Container Security Operator, you must uninstall the Operator and delete the `imagemanifestvulns.secscan.quay.redhat.com` custom resource definition (CRD).
10
11
11
12
.Procedure
@@ -27,7 +28,7 @@ To uninstall the Container Security Operator, you must uninstall the Operator an
Copy file name to clipboardExpand all lines: modules/security-hardening-how.adoc
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,7 @@
6
6
[id="security-hardening-how_{context}"]
7
7
= Choosing how to harden {op-system}
8
8
9
+
[role="_abstract"]
9
10
Direct modification of {op-system} systems in {product-title} is discouraged. Instead, you should think of modifying systems in pools of nodes, such as worker nodes and control plane nodes. When a new node is needed, in non-bare metal installs, you can request a new node of the type you want and it will be created from an {op-system} image plus the modifications you created earlier.
10
11
11
12
There are opportunities for modifying {op-system} before installation, during installation, and after the cluster is up and running.
@@ -31,9 +32,13 @@ You can interrupt the {product-title} installation process and change Ignition c
31
32
== Hardening after the cluster is running
32
33
After the {product-title} cluster is up and running, there are several ways to apply hardening features to {op-system}:
33
34
34
-
* Daemon set: If you need a service to run on every node, you can add
35
-
that service with a link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes `DaemonSet` object].
35
+
* Daemon set: If you need a service to run on every node, you can add that service with a Kubernetes `DaemonSet` object.
36
36
37
37
* Machine config: `MachineConfig` objects contain a subset of Ignition configs in the same format. By applying machine configs to all worker or control plane nodes, you can ensure that the next node of the same type that is added to the cluster has the same changes applied.
38
38
39
39
All of the features noted here are described in the {product-title} product documentation.
Copy file name to clipboardExpand all lines: modules/security-hardening-what.adoc
+14-3Lines changed: 14 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,16 +6,27 @@
6
6
[id="security-hardening-what_{context}"]
7
7
= Choosing what to harden in {op-system}
8
8
9
+
[role="_abstract"]
10
+
With the knowledge of what operating system features you want to harden, you can decide how to best configure and enforce security profiles in {op-system}.
11
+
9
12
ifdef::openshift-origin[]
10
-
For information on how to approach security for any {op-system-base} system, see the link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9#Security[Security] category in the Red{nbsp}Hat Enterprise Linux 9 documentation.
13
+
For information on how to approach security for any {op-system-base} system, see the Security category in the Red{nbsp}Hat Enterprise Linux 9 documentation.
11
14
12
15
Use these documents to learn about managing security updates, security hardening, securing networks, and other security measures.
For information on how to approach security for any {op-system-base} system, see the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#scanning-container-and-container-images-for-vulnerabilities_scanning-the-system-for-security-compliance-and-vulnerabilities[{op-system-base} 9 Security Hardening] guide.
18
+
For information on how to approach security for any {op-system-base} system, see the {op-system-base} 9 Security Hardening guide.
16
19
17
20
Use this guide to learn how to approach cryptography, evaluate vulnerabilities, and assess threats to various services.
18
21
Likewise, you can learn how to scan for compliance standards, check file integrity, perform auditing, and encrypt storage devices.
19
22
endif::[]
20
23
21
-
With the knowledge of what features you want to harden, you can then decide how to harden them in {op-system}.
Copy file name to clipboardExpand all lines: modules/security-pod-scan-cso.adoc
+7-6Lines changed: 7 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,7 @@
6
6
[id="security-pod-scan-cso_{context}"]
7
7
= Installing the {rhq-cso}
8
8
9
+
[role="_abstract"]
9
10
You can install the {rhq-cso} from the {product-title} web console Operator Hub, or by using the CLI.
10
11
11
12
.Prerequisites
@@ -48,7 +49,7 @@ $ oc get packagemanifests container-security-operator \
48
49
| head -1
49
50
----
50
51
+
51
-
.Example output
52
+
**Example output**
52
53
+
53
54
[source,terminal]
54
55
----
@@ -65,15 +66,15 @@ metadata:
65
66
name: container-security-operator
66
67
namespace: openshift-operators
67
68
spec:
68
-
channel: ${CHANNEL} <1>
69
+
channel: ${CHANNEL}
69
70
installPlanApproval: Automatic
70
71
name: container-security-operator
71
72
source: redhat-operators
72
73
sourceNamespace: openshift-marketplace
73
-
startingCSV: ${STARTING_CSV} <2>
74
+
startingCSV: ${STARTING_CSV}
74
75
----
75
-
<1> Specify the value you obtained in the previous step for the `spec.channel` parameter.
76
-
<2> Specify the value you obtained in the previous step for the `spec.startingCSV` parameter.
76
+
+
77
+
For the `spec.channel` parameter, specify the value you obtained in the previous step (such as `stable-3.8`). For the `spec.startingCSV` parameter, specify the value you obtained in the previous step (such as `container-security-operator.v3.8.9`).
77
78
78
79
.. Enter the following command to apply the configuration:
0 commit comments