Skip to content

Commit b206e80

Browse files
butler54gaurav-nelson
butler54
authored and
gaurav-nelson
committed
feat: confidential container for zero trust validated pattenr docs
Signed-off-by: Chris Butler <chris.butler@redhat.com>
1 parent 6f604e2 commit b206e80

File tree

2 files changed

+228
-0
lines changed

2 files changed

+228
-0
lines changed

‎content/patterns/layered-zero-trust/_index.adoc‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,11 @@ The solution integrates many Red{nbsp}Hat components to offer:
7070
* Cryptographic signing and verification.
7171
* SBOM vulnerability analysis.
7272

73+
It also optionally integrates hosting of workloads in using confidential containers:
74+
75+
* Per container confidential workload management using OpenShift Sandboxed containers, built on Kata containers.
76+
* Remote attestation enforced with a key broker service via Red Hat build of Trustee.
77+
7378
[id="architecture"]
7479
=== Architecture
7580

@@ -107,6 +112,14 @@ The pattern consists of the following key components:
107112

108113
* link:https://docs.redhat.com/es/documentation/red_hat_trusted_profile_analyzer/2.2[Red{nbsp}Hat Trusted Profile Analyzer (RHTPA)]
109114
** Provides the storage and management means for _Software Bill of Materials_ (SBOMs), with cross-referencing capabilities between SBOMs and CVEs/Security Advisories.
115+
Optionally:
116+
117+
* link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/index[Red{nbsp}Hat OpenShift sandboxed containers]
118+
** Provides the ability to create confidential containers
119+
120+
* link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_red_hat_build_of_trustee/index[Red{nbsp}Hat build of Trustee]
121+
** Acts as a key broker service and measures the security of confidential containers
122+
110123

111124
[id="sidecar-pattern"]
112125
==== Sidecar pattern

‎content/patterns/layered-zero-trust/lzt-confidential-containers.adoc‎

Lines changed: 215 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,215 @@
1+
---
2+
title: Confidential containers
3+
weight: 40
4+
aliases: /layered-zero-trust/lzt-confidential-containers/
5+
---
6+
7+
:toc:
8+
:imagesdir: /images
9+
:_mod-docs-content-type: ASSEMBLY
10+
include::modules/comm-attributes.adoc[]
11+
12+
[id="lzt-about-coco"]
13+
= Use case: Confidential containers
14+
15+
[role="_abstract"]
16+
Confidential computing is a technology that protects data in use.
17+
Red{nbsp}Hat's link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/index[OpenShift sandboxed containers Confidential Containers] (CoCo) feature uses Trusted Execution Environments (TEEs). TEEs are specialized CPU features from AMD, Intel, and others that create isolated, encrypted memory spaces (data in use) with cryptographic proof of integrity.
18+
These hardware guarantees mean workloads can prove they have not been tampered with, and secrets are protected, even from infrastructure administrators.
19+
20+
Confidential containers within the layered zero-trust pattern integrate zero-trust workload identity management.
21+
You get defense in-depth: cryptographic identity verification and hardware-rooted trust.
22+
23+
Using confidential containers in the layered zero-trust pattern is optional because it imposes specific hardware constraints.
24+
25+
[IMPORTANT]
26+
====
27+
Using confidential containers restricts the platform to Microsoft Azure.
28+
You also need access to and quota for link:https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-options[specific Azure instance types] in the region where the cluster is deployed.
29+
30+
Ensure that you check the availability of appropriate confidential virtual machines before testing.
31+
====
32+
33+
Confidential containers are intentionally not the default deployment option.
34+
Therefore, you must perform extra steps to deploy confidential containers.
35+
36+
[id="lzt-set-up-azure-coco"]
37+
== Setting up an Azure cluster
38+
39+
Confidential containers on Azure use link:https://www.redhat.com/ja/blog/red-hat-openshift-sandboxed-containers-peer-pods-solution-overview[peer pods].
40+
This does not impose requirements on the base cluster type beyond sufficient capacity.
41+
This pattern has been tested with Azure Red{nbsp}Hat OpenShift clusters and OpenShift clusters installed using the `openshift-install` program.
42+
43+
[NOTE]
44+
====
45+
To provision peer pods, the OpenShift cluster must be able to communicate with Azure APIs.
46+
The pattern uses the same Azure service account used during cluster provisioning to create:
47+
48+
* VM Templates
49+
* The peer pod VMs
50+
* A link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.10/html/deploying_confidential_containers/deploying-cc_azure-cc#configuring-outbound-connections_azure-cc[NAT gateway] to allow outbound traffic from the peer pods
51+
====
52+
53+
[id="lzt-set-up-repo-coco"]
54+
== Setting up the repository
55+
56+
.Prerequisites
57+
58+
* You must have completed the xref:../lzt-getting-started#lzt-repository-setup[repository setup] instructions.
59+
60+
.Procedure
61+
62+
. Verify that you are using `my-branch`:
63+
+
64+
[source,terminal]
65+
----
66+
$ git status
67+
On branch my-branch
68+
Your branch is up to date with 'origin/my-branch'.
69+
70+
nothing to commit, working tree clean
71+
----
72+
73+
. Change `clusterGroupName` to `coco-dev` in the `values-global.yaml` file:
74+
+
75+
[source,yaml]
76+
----
77+
...
78+
main:
79+
clusterGroupName: coco-dev
80+
...
81+
----
82+
83+
. Commit and push the change to your branch:
84+
+
85+
[source,terminal]
86+
----
87+
$ git add values-global.yaml
88+
$ git commit -m 'Change to CoCo cluster group'
89+
$ git push origin my-branch
90+
----
91+
92+
[id="lzt-configure-secrets-coco"]
93+
== Configuring secrets
94+
95+
To secure confidential containers, the Key Broker Service, Red{nbsp}Hat build of Trustee, requires the configuration of extra secrets.
96+
Most credentials are automatically generated on the cluster where Trustee is deployed. However, you must generate the administrative credentials for Trustee off-cluster.
97+
98+
[NOTE]
99+
====
100+
Red{nbsp}Hat recommends reading the full instructions on link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_red_hat_build_of_trustee/deploying-trustee_azure-trustee[configuring and deploying Red{nbsp}Hat build of Trustee].
101+
The Trustee role is security-sensitive.
102+
====
103+
104+
.Procedure
105+
106+
. Create a local copy of the secret values file that can safely include credentials:
107+
+
108+
[source,terminal]
109+
----
110+
$ cp values-secret.yaml.template ~/values-secret-layered-zero-trust.yaml
111+
----
112+
113+
. Uncomment the required additional secrets for the `coco-dev` chart. Each required secret has `# Required for coco-dev clusterGroup` comment above the secret.
114+
+
115+
[source,terminal]
116+
----
117+
$ vim ~/values-secret-layered-zero-trust.yaml
118+
----
119+
120+
. Generate the link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_red_hat_build_of_trustee/deploying-trustee_azure-trustee#creating-trustee-secret_azure-trustee[admin API authentication secret]:
121+
+
122+
[source,terminal]
123+
----
124+
$ cd ~/
125+
$ openssl genpkey -algorithm ed25519 > kbsPrivateKey
126+
$ openssl pkey -in kbsPrivateKey -pubout -out kbsPublicKey
127+
----
128+
+
129+
[NOTE]
130+
====
131+
The `values-secret.yaml.template` file references the `kbsPublicKey` file name specified here.
132+
Using a different path requires changes to `~/values-secrets-layered-zero-trust.yaml`.
133+
====
134+
135+
[id="deploy-coco-patterns-file"]
136+
== Deploying the Confidential Containers variant
137+
138+
The deployment of the confidential containers variant is same as the default version:
139+
140+
. Log in to your {ocp} cluster:
141+
142+
.. Using the `oc` CLI:
143+
* Get an API token by visiting `pass:[https://oauth-openshift.apps.<your_cluster>.<domain>/oauth/token/request]`.
144+
* Log in with the retrieved token:
145+
+
146+
[source,terminal]
147+
----
148+
$ oc login --token=<retrieved_token> --server=https://api.<your_cluster>.<domain>:6443
149+
----
150+
151+
.. Using `KUBECONFIG`:
152+
+
153+
[source,terminal]
154+
----
155+
$ export KUBECONFIG=~/<path_to_kubeconfig>
156+
----
157+
158+
. Run the pattern deployment script:
159+
+
160+
[source,terminal]
161+
----
162+
$ ./pattern.sh make install
163+
----
164+
165+
[NOTE]
166+
====
167+
The deployment of the OpenShift sandboxed containers Operator takes time and might result in timeouts in the installation script.
168+
This is because the `./pattern.sh make install` script waits for the Argo CD applications to become healthy.
169+
====
170+
171+
[id="lzt-verify-deployment-coco"]
172+
=== Verifying the deployment
173+
174+
The Layered Zero-Trust pattern provisions and manages every component through {ocp} GitOps. After you deploy the pattern, verify that all components are running correctly.
175+
176+
The Layered Zero-Trust pattern installs the following two {ocp} GitOps instances on your hub cluster. You can view these instances in the {ocp} web console by using the **Application Selector** (the icon with nine small squares) in the top navigation bar.
177+
178+
. **Cluster Argo CD**: Deploys an *app-of-apps* application named `layered-zero-trust-coco-dev`. This application installs the pattern's components.
179+
. **Coco-debugging Argo CD**: Manages the Cluster Argo CD instance and the individual components that belong to the pattern on the hub {ocp} instance.
180+
181+
If every Argo CD application reports a **Healthy** status, the pattern has been deployed successfully.
182+
183+
[id="lzt-troubleshoot-coco"]
184+
=== Troubleshooting confidential containers workloads
185+
186+
If you encounter any issues with the confidential containers variant of the layered zero-trust pattern, first test deploying the default `hub` `clusterGroup`.
187+
188+
.Procedure
189+
190+
. Run a health check of Argo CD applications:
191+
+
192+
[source,terminal]
193+
----
194+
$ ./pattern.sh make argo-healthcheck
195+
----
196+
197+
. If all applications except `hello-coco` are healthy, the Operators have deployed, but the peer pods have not.
198+
199+
. Check whether the pod is visible in the namespace:
200+
+
201+
[source,terminal]
202+
----
203+
$ oc get pods -n zero-trust-workload-identity-manager spire-agent-cc -o yaml
204+
----
205+
206+
. If the pod manifest is not visible, the Sandboxed Container Operator has not yet deployed.
207+
208+
. If the pod is visible, check for the existence of and events for the peer pods:
209+
+
210+
[source,terminal]
211+
----
212+
$ oc get peerpods -A -o yaml
213+
----
214+
215+
. The most likely cause of failure is insufficient Azure quota.

0 commit comments

Comments
 (0)