Skip to content

Commit e59406f

Browse files
butler54butler54
committed
feat: confidential container for zero trust validated pattenr docs
Signed-off-by: Chris Butler <chris.butler@redhat.com>
1 parent 4dc36d7 commit e59406f

File tree

2 files changed

+230
-0
lines changed

2 files changed

+230
-0
lines changed

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

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -68,6 +68,11 @@ The solution integrates many Red{nbsp}Hat components to offer:
6868
* Certificate management for secure communications.
6969
* External secret management integration.
7070

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

@@ -94,6 +99,15 @@ The pattern consists of the following key components:
9499
* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14[{rh-rhacm-first}]
95100
** Provides a management control plane in multi-cluster scenarios.
96101

102+
Optionally:
103+
104+
* link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/index[Red{nbsp}Hat OpenShift sandboxed containers]
105+
** Provides the ability to create confidential containers
106+
107+
* 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]
108+
** Acts as a key broker service and measures the security of confidential containers
109+
110+
97111
[id="sidecar-pattern"]
98112
==== Sidecar pattern
99113

@@ -127,3 +141,4 @@ The following technologies are used in this solution:
127141
* *Compliance Operator*: Provides ability to scan and remediate cluster hardening based on profiles
128142
* *QTodo application*: Serves as a sample Quarkus-based application to show zero trust principles.
129143
* *PostgreSQL database*: Provides the backend database for the demonstration application.
144+

‎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: Confidenial containers variant
3+
weight: 10
4+
aliases: /layered-zero-trust/lzt-confidential-containers/
5+
---
6+
7+
8+
:toc:
9+
:imagesdir: /images
10+
:_mod-docs-content-type: ASSEMBLY
11+
include::modules/comm-attributes.adoc[]
12+
13+
[id="lzt-about-coco"]
14+
15+
Confidential computing is a technology to prortect data in use.
16+
Red{nbsp}Hat's link:link:https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/index[OpenShift sandboxed containers new Confidential Containers feature] (CoCo) uses Trusted Execution Environments (TEEs), which are specialized CPU features from AMD, Intel, and others that create isolated, encrypted memory spaces (data in use) with cryptographic proof of integrity.
17+
These hardware guarantees mean workloads can prove they haven't been tampered with, and secrets can be protected, even from infrastructure administrators.
18+
19+
Confidential containers within the layered-zero-trust pattern integrates zero trust workload identity management.
20+
You get defense in depth: cryptographic identity verification PLUS hardware rooted trust.
21+
22+
For the layered-zero-trust pattern the use of confidential containers is an optional configuration as it imposes specific hardware constraints.
23+
24+
[WARNING]
25+
====
26+
Using confidential containers restricts the platform the user is on to Microsoft Azure.
27+
It also requires access and quota for link:https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-options[specific Azure instance types] for the region the cluster is deployed.
28+
29+
Ensure you pre-check availability of appropriate confidential virtual machines when testing.
30+
====
31+
32+
33+
[id="lzt-deploying-coco"]
34+
=
35+
Confidential containers is intentionally not the default deployment option.
36+
This introduces a small number of extra steps to deploy confidential containers.
37+
38+
39+
== Azure cluster setup
40+
Confidential containers on Azure use link:https://www.redhat.com/ja/blog/red-hat-openshift-sandboxed-containers-peer-pods-solution-overview[peer-pods].
41+
This does not impose requirements on the base cluster type beyond sufficient capacity.
42+
This pattern has been tested with both Azure Red{nbsp}Hat OpenShift clusters as well as OpenShift clusters installed using `openshift_installer`.
43+
44+
[NOTE]
45+
====
46+
In order to provision peer-pods the OpenShift cluster will need to be able to communicate with Azure's apis.
47+
The pattern uses the same Azure service account used during cluster provisioning to create:
48+
49+
* VM Templates
50+
* The peer-pod VMs
51+
* 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
52+
====
53+
54+
55+
== Repository setup
56+
57+
Prerequisite: First read the repository setup here link:../lzt-getting-started#lzt-repository-setup[here].
58+
59+
. Assuming you are checked out on `my-branch`
60+
+
61+
[source,terminal]
62+
----
63+
$ git status
64+
On branch my-branch
65+
Your branch is up to date with 'origin/my-branch'.
66+
67+
nothing to commit, working tree clean
68+
----
69+
70+
. Change the `clusterGroupName` to `coco-dev` in `values-global.yaml` e.g.:
71+
+
72+
[source,yaml]
73+
----
74+
...
75+
main:
76+
clusterGroupName: coco-dev
77+
...
78+
----
79+
+
80+
. Commit and push the change to your branch
81+
+
82+
[source, terminal]
83+
---
84+
$ git add values-global.yaml
85+
$ git commit -m 'Change to CoCo cluster group'
86+
$ git push origin my-branch
87+
---
88+
+
89+
. Your respository is now ready.
90+
91+
== Secrets setup
92+
93+
In order to secure confidential containers the key broker service, Red{nbsp}Hat build of Trustee, requires extra secrets to be configured.
94+
Most credentials are automatically generated on the cluster Trustee is deployed on. However, the administrative credentials for Trustee must be generated off cluster.
95+
96+
[NOTE]
97+
====
98+
It's highly recommended to read through 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].
99+
Trustee's role is security sensitive.
100+
====
101+
. Create a local copy of the secret values file that can safely include
102+
credentials. Run the following command:
103+
+
104+
[source,terminal]
105+
----
106+
$ cp values-secret.yaml.template ~/values-secret-layered-zero-trust.yaml
107+
----
108+
+
109+
. Uncomment the required additional secrets for the `coco-dev` chart. Each of the secrets required has `# Required for coco-dev clusterGroup` above the secret.
110+
+
111+
[source,terminal]
112+
----
113+
$ vim ~/values-secret-layered-zero-trust.yaml
114+
----
115+
+
116+
. 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 authentiation secret].
117+
+
118+
[source,terminal]
119+
----
120+
$ cd ~/
121+
openssl genpkey -algorithm ed25519 > kbsPrivateKey
122+
openssl pkey -in kbsPrivateKey -pubout -out kbsPublicKey
123+
----
124+
+
125+
[NOTE]
126+
====
127+
The file name of the `kbsPublicKey` specified here is referenced in the `values-secret.yaml.template` file.
128+
Using a different path will require changes to `~/values-secrets-layered-zero-trust.yaml`
129+
====
130+
131+
[id="deploying-coco-patternsh-file"]
132+
== Deploying the Confidential Containers variant of the layed-zero trust pattern
133+
134+
The deployment of the confidential containers variant mirrors that of the default version:
135+
136+
. Login to your {ocp} cluster:
137+
138+
.. By using the `oc` CLI:
139+
* Get an API token by visiting `pass:[https://oauth-openshift.apps.<your_cluster>.<domain>/oauth/token/request]`.
140+
* Log in with the retrieved token:
141+
+
142+
[source,terminal]
143+
----
144+
$ oc login --token=<retrieved_token> --server=https://api.<your_cluster>.<domain>:6443
145+
----
146+
147+
.. By using KUBECONFIG:
148+
+
149+
[source,terminal]
150+
----
151+
$ export KUBECONFIG=~/<path_to_kubeconfig>
152+
----
153+
154+
. Run the pattern deployment script:
155+
+
156+
[source,terminal]
157+
----
158+
$ ./pattern.sh make install
159+
----
160+
161+
[NOTE]
162+
====
163+
The deployment of the OpenShift sandboxed containers operator takes time and may result in time-outs in the installation script.
164+
This is as the `./pattern.sh make install` script waiting for the ArgoCD applications to become healthy.
165+
====
166+
167+
168+
[id="lzt-verify-deployment-coco"]
169+
=== Verify the deployment
170+
171+
The Layered Zero-Trust pattern provisions every component and manages them through {ocp} GitOps. After you deploy the pattern, verify that all components are running correctly.
172+
173+
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.
174+
175+
. **Cluster Argo CD**: Deploys an *App-of-Apps* application named `layered-zero-trust-coco-dev`. This application installs the pattern's components.
176+
. **Coco-debuggingv Argo CD**: Manages Cluster Argo CD instance and the individual components that belong to the pattern on the hub {ocp} instance.
177+
178+
If every Argo CD application reports a **Healthy** status, the pattern has been deployed successfully.
179+
180+
181+
=== Likely deployment failures for confidential containers workloads.
182+
183+
If you encounter an issue with the confidential containers variant of the layered zero trust pattern it's highly recommended to first test deploying the default `hub` `clusterGroup`.
184+
Below are some triage steps:
185+
186+
187+
. Run a healthcheck of ArgoCD applications:
188+
+
189+
[source,terminal]
190+
----
191+
$ ./pattern.sh make argo-healthcheck
192+
----
193+
+
194+
195+
. If all the applications except for `hello-coco` are healthy the operators have deployed, but as yet not the peer-pods.
196+
197+
. Check whether the pod is visible in namespace:
198+
+
199+
[source,terminal]
200+
----
201+
$ oc get pods -n zero-trust-workload-identity-manager spire-agent-cc -o yaml
202+
----
203+
+
204+
205+
. If the pod manifest is not visible the sandboxed container operator has not yet deployed
206+
207+
. If the pod is visible check for the existence and events for the peer pods
208+
+
209+
[source,terminal]
210+
----
211+
$ oc get peerpods -A -o yaml
212+
----
213+
+
214+
215+
. The most likely failure here is insufficient Azure quota.

0 commit comments

Comments
 (0)