Skip to content

Commit 63c2f00

Browse files
prmerger-automator[bot]prmerger-automator[bot]
authored
Merge pull request #290656 from johnmarco/jm-aro-coco-redux
ARO CoCo rework
2 parents ec10a72 + 479f352 commit 63c2f00

File tree

2 files changed

+221
-17
lines changed

2 files changed

+221
-17
lines changed

‎articles/openshift/confidential-containers-deploy.md

Lines changed: 220 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ ms.author: johnmarc
66
ms.service: azure-redhat-openshift
77
keywords: confidential containers, aro, deploy, openshift, red hat
88
ms.topic: how-to
9-
ms.date: 11/04/2024
9+
ms.date: 11/21/2024
1010
ms.custom: template-how-to
1111
---
1212

@@ -40,7 +40,7 @@ After deploying OpenShift Sandboxed Containers, deploy Confidential Containers.
4040

4141
1. Create the Trustee config map.
4242

43-
1. Configure attestation policies (optional).
43+
1. Configure Trustee.
4444

4545
1. Create the KbsConfig custom resource.
4646

@@ -619,35 +619,151 @@ Create a secure route with edge TLS termination for Trustee. External ingress tr
619619
`$ oc apply -f kbs-config-cm.yaml`
620620
621621
622+
### Configure Trustee
622623
623-
### Configure attestation policies
624+
Configure the following Trustee settings:
624625
625-
You can configure the following attestation policy settings:
626-
627-
**Reference values**
626+
**Configure reference values**
628627
629628
You can configure reference values for the Reference Value Provider Service (RVPS) by specifying the trusted digests of your hardware platform.
630629
631630
The client collects measurements from the running software, the Trusted Execution Environment (TEE) hardware and firmware and it submits a quote with the claims to the Attestation Server. These measurements must match the trusted digests registered to the Trustee. This process ensures that the confidential VM (CVM) is running the expected software stack and hasn't been tampered with.
632631
633-
**Secrets for clients**
632+
1. Create an `rvps-configmap.yaml` manifest file:
633+
634+
```
635+
apiVersion: v1
636+
kind: ConfigMap
637+
metadata:
638+
name: rvps-reference-values
639+
namespace: trustee-operator-system
640+
data:
641+
reference-values.json: |
642+
[
643+
]
644+
```
645+
646+
For `reference-values.json` specify the trusted digests for your hardware platform if required. Otherwise, leave it empty.
647+
648+
1. Create the RVPS config map by running the following command:
649+
650+
`$ oc apply -f rvps-configmap.yaml`
651+
652+
653+
654+
655+
<!--
634656
635-
You must create one or more secrets to share with attested clients.
657+
**Secret with custom keys for clients** (Optional)
636658
637-
**Resource access policy**
659+
You can create a secret that contains one or more custom keys for Trustee clients.
660+
661+
**Resource access policy** (Optional)
638662
639663
You must configure a policy for the Trustee policy engine to determine which resources to access.
640664
641665
Don't confuse the Trustee policy engine with the Attestation Service policy engine, which determines the validity of TEE evidence.
642666
643-
**Attestation policy**
667+
-->
668+
669+
**Create your own attestation policy**
670+
671+
You can overwrite the default attestation policy by creating your own attestation policy.
672+
673+
1. Create an attestation-policy.yaml manifest file according to the following example:
674+
675+
```
676+
apiVersion: v1
677+
kind: ConfigMap
678+
metadata:
679+
name: attestation-policy
680+
namespace: trustee-operator-system
681+
data:
682+
default.rego: |
683+
package policy
684+
import future.keywords.every
685+
686+
default allow = false
687+
688+
allow {
689+
every k, v in input {
690+
judge_field(k, v)
691+
}
692+
}
693+
694+
judge_field(input_key, input_value) {
695+
has_key(data.reference, input_key)
696+
reference_value := data.reference[input_key]
697+
match_value(reference_value, input_value)
698+
}
699+
700+
judge_field(input_key, input_value) {
701+
not has_key(data.reference, input_key)
702+
}
703+
704+
match_value(reference_value, input_value) {
705+
not is_array(reference_value)
706+
input_value == reference_value
707+
}
708+
709+
match_value(reference_value, input_value) {
710+
is_array(reference_value)
711+
array_include(reference_value, input_value)
712+
}
713+
714+
array_include(reference_value_array, input_value) {
715+
reference_value_array == []
716+
}
717+
718+
array_include(reference_value_array, input_value) {
719+
reference_value_array != []
720+
some i
721+
reference_value_array[i] == input_value
722+
}
723+
724+
has_key(m, k) {
725+
_ = m[k]
726+
}
727+
```
728+
729+
For the `package policy`, the attestation policy follows the Open Policy Agent specification. In this example, the attestation policy compares the claims provided in the attestation report to the reference values registered in the RVPS database. The attestation process is successful only if all the values match.
730+
731+
1. Create the attestation policy config map by running the following command:
732+
733+
`$ oc apply -f attestation-policy.yaml`
644734
645-
Optional: You can overwrite the default attestation policy by creating your own attestation policy.
646735
647736
**Provisioning Certificate Caching Service for TDX**
648737
649738
If your TEE is Intel Trust Domain Extensions (TDX), you must configure the Provisioning Certificate Caching Service (PCCS). The PCCS retrieves Provisioning Certification Key (PCK) certificates and caches them in a local database.
650739
740+
1. Create a tdx-config.yaml manifest file:
741+
742+
```
743+
apiVersion: v1
744+
kind: ConfigMap
745+
metadata:
746+
name: tdx-config
747+
namespace: trustee-operator-system
748+
data:
749+
sgx_default_qcnl.conf: | \
750+
{
751+
"collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/",
752+
"pccs_url": "<pccs_url>"
753+
}
754+
```
755+
756+
For `pccs_url`, specify the PCCS URL, for example, https://localhost:8081/sgx/certification/v4/.
757+
758+
1. Create the TDX config map by running the following command:
759+
760+
`$ oc apply -f tdx-config.yaml`
761+
762+
763+
764+
<!--
765+
766+
651767
1. Create an `rvps-configmap.yaml` manifest file:
652768
653769
```
@@ -701,7 +817,7 @@ If your TEE is Intel Trust Domain Extensions (TDX), you must configure the Provi
701817
702818
`$ oc apply -f resourcepolicy-configmap.yaml`
703819
704-
1. Optional: Create an attestation-policy.yaml manifest file according to the following example:
820+
1. Create an attestation-policy.yaml manifest file according to the following example:
705821
706822
```
707823
apiVersion: v1
@@ -785,10 +901,88 @@ If your TEE is Intel Trust Domain Extensions (TDX), you must configure the Provi
785901
786902
`$ oc apply -f tdx-config.yaml`
787903
904+
-->
905+
906+
**Create a secret for container image signature verification**
907+
908+
If you use container image signature verification, you must create a secret that contains the public container image signing key. The Trustee Operator uses the secret to verify the signature, ensuring that only trusted and authenticated container images are deployed in your environment.
909+
910+
1. Create a secret for container image signature verification by running the following command:
911+
912+
```
913+
$ oc apply secret generic <type> \
914+
--from-file=<tag>=./<public_key_file> \
915+
-n trustee-operator-system
916+
```
917+
918+
- Specify the KBS secret type, for example, `img-sig`.
919+
- Specify the secret tag, for example, `pub-key`, and the public container image signing key.
920+
921+
1. Record the `<type>` value. You must add this value to the spec.kbsSecretResources key when you create the KbsConfig custom resource.
922+
923+
**Create the container image signature verification policy**
924+
925+
You must create the container image signature verification policy because signature verification is always enabled.
926+
927+
> [!IMPORTANT]
928+
> If this policy is missing, the pods will not start. If you are not using container image signature verification, you create the policy without signature verification.
929+
>
930+
1. Create a security-policy-config.json file according to the following examples:
931+
932+
Without signature verification:
933+
934+
```
935+
{
936+
"default": [
937+
{
938+
"type": "insecureAcceptAnything"
939+
}],
940+
"transports": {}
941+
}
942+
```
943+
944+
With signature verification:
945+
946+
```
947+
{
948+
"default": [
949+
{
950+
"type": "insecureAcceptAnything"
951+
],
952+
"transports": {
953+
"<transport>": {
954+
"<registry>/<image>":
955+
[
956+
{
957+
"type": "sigstoreSigned",
958+
"keyPath": "kbs:///default/<type>/<tag>"
959+
}
960+
]
961+
}
962+
}
963+
}
964+
```
965+
966+
- Specify the image repository for transport, for example, "docker".
967+
- Specify the container registry and image, for example, "quay.io/my-image".
968+
- Specify the type and tag of the container image signature verification secret that you created, for example, "img-sig/pub-key".
969+
970+
1. Create the security policy by running the following command:
971+
972+
```
973+
$ oc apply secret generic security-policy \
974+
--from-file=osc=./<security-policy-config.json> \
975+
-n trustee-operator-system
976+
```
977+
978+
Do not alter the secret type, security-policy, or the key, osc.
979+
980+
The security-policy secret is specified in the `spec.kbsSecretResources` key of the KbsConfig custom resource.
981+
788982
789983
### Create the KbsConfig custom resource
790984
791-
You must create the KbsConfig custom resource to launch Trustee. Then, you check the Trustee pods and pod logs to verify the configuration.
985+
You must create the KbsConfig custom resource to launch Trustee.
792986
793987
1. Create a `kbsconfig-cr.yaml` manifest file:
794988
@@ -809,15 +1003,25 @@ You must create the KbsConfig custom resource to launch Trustee. Then, you check
8091003
kbsAuthSecretName: kbs-auth-public-key
8101004
kbsDeploymentType: AllInOneDeployment
8111005
kbsRvpsRefValuesConfigMapName: rvps-reference-values
812-
kbsSecretResources: ["kbsres1"]
1006+
kbsSecretResources: ["kbsres1", "security-policy", "<type>"]
8131007
kbsResourcePolicyConfigMapName: resource-policy
1008+
# tdxConfigSpec:
1009+
# kbsTdxConfigMapName: tdx-config
1010+
# kbsAttestationPolicyConfigMapName: attestation-policy
1011+
# kbsServiceType: <service_type>
8141012
```
815-
1013+
- Specify the `type` value of the container image signature verification secret if you created the secret, for example, `img-sig`.
1014+
- Uncomment `tdxConfigSpec.kbsTdxConfigMapName: tdx-config` for Intel Trust Domain Extensions.
1015+
- Uncomment `kbsAttestationPolicyConfigMapName: attestation-policy` if you create a customized attestation policy.
1016+
- Uncomment `kbsServiceType: <service_type>` if you create a service type, other than the default ClusterIP service, to expose applications within the cluster external traffic. You can specify `NodePort`, `LoadBalancer`, or `ExternalName`.
1017+
8161018
1. Create the KbsConfig custom resource by running the following command:
8171019
8181020
`$ oc apply -f kbsconfig-cr.yaml`
8191021
820-
#### Verification
1022+
#### Verify the Trustee configuration
1023+
1024+
Verify the Trustee configuration by checking the Trustee pods and logs.
8211025
8221026
1. Set the default project by running the following command:
8231027

‎articles/openshift/toc.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -124,7 +124,7 @@
124124
href: howto-deploy-java-jboss-enterprise-application-platform-app.md
125125
- name: Confidential Containers
126126
items:
127-
- name: Use Confidential Containers to protect senstive data
127+
- name: Use Confidential Containers to protect sensitive data
128128
href: confidential-containers-overview.md
129129
- name: Deploy Confidential Containers
130130
href: confidential-containers-deploy.md

0 commit comments

Comments
 (0)