coco-pattern

This is a validated pattern for deploying confidential containers on OpenShift.

There are two topologies for deploying this pattern:

1. Default using a single cluster. This breaks the RACI expected in a remote attestation architecture, however, makes it easier to test. This uses the simple clusterGroup.
2. A more secure operating model that has two clusters:
   • One in a "trusted" zone where the remote attestation, KMS and Key Broker infrastructure are deployed. This is also the Advanced Cluster Manager Hub cluster. It uses the trusted-hub clusterGroup.
   • A second where a subset of workloads are deployed in confidential containers. It uses the spoke clusterGroup

The current version of this application the confidential containers assumes deployment to Azure.

On the cluster where confidential workloads are deployed two sample applications are deployed:

1. Sample hello world applications to allow users to experiment with the policies for CoCo and the KBS (trustee).
2. A sample application kbs-access which presents secrets obtained from trustee to a web service. This is designed to allow users to test locked down environments.

Future work includes:

1. Supporting a multiple cluster deployment Done
2. Supporting multiple infrastructure providers - Work in Progress.
3. Supporting air-gapped deployments - Work in Progress.
4. Supporting a more sophisticated workload such as confidential AI inference with protected GPUs.

Current constraints and assumptions

• Only currently is known to work with azure as the provider of confidential vms via peer-pods.
• Below version 3.1, if not using ARO you must either provide your own CA signed certs, or use let's encrypt.
• Must be on 4.16.14 or later.

Major versions

3.*

Version 3.* of the pattern is currently constrained to support the general availability releases of coco.

• (OpenShift Sandboxed Containers Operator) 1.10.* and above
• Trustee 0.4.*

This limits support to OpenShift 4.16 and higher.

The pattern has been tested on Azure for two installation methods:

1. Installing onto an ARO cluster
2. Self managed OpenShift install using the openshift-install CLI.

Known limitations

Additional configuration is required to pull secrets from authenticated registries.

2.*

Version 2.* of the pattern is currently constrained to support:

• (OpenShift Sandboxed Containers Operator) 1.9.*
• Trustee 0.3.*

This limits support to OpenShift 4.16 and higher.

The pattern has been tested on Azure for two installation methods:

1. Installing onto an ARO cluster
2. Self managed OpenShift install using the openshift-install CLI.

1.0.0

1.0.0 supports OpenShift Sandboxed containers version 1.8.1 along with Trustee version 0.2.0.

The pattern has been tested on Azure for one installation method:

1. Self managed OpenShift install using the openshift-install CLI
2. Installing on top of an existing Azure Red Hat OpenShift (ARO) cluster

Changing deployment topoloiges

Today the demo has two deployment topologies The most important change is what clusterGroup is deployed to your main or 'hub' cluster.

You can change between behaviour by configuring global.main.clusterGroupName key in the values-global.yaml file.

• values-simple.yaml: or the simple cluster group is the default for the pattern. It deploys everything in one cluster. -values-trusted-hub: or the trusted-hub cluster group can be configured as the main cluster group. A second cluster should be deployed with the spoke cluster group. Follow instructions here to add the second cluster.

Setup instructions

Default single cluster setup with values-simple.yaml

The instructions here presume you have a cluster. See further down for provisioning instructions for a cluster.

Fork and Clone the GitHub repository

1. Following standard validated patterns workflow fork the repository and clone to your development environment which has podman and git
2. If using a particular version (e.g. 1.0.0) checkout the correct tag.

Tip

Forking is essential as the validated pattern uses ArgoCD to reconcile it's state against your remote (forked) repository.

Configuring required secrets / parameters

The secrets here secure Trustee and the peer-pod vms. Mostly they are for demonstration purposes. This only has to be done once.

1. Run sh scripts/gen-secrets.sh

Note

Once generated this script will not override secrets. Be careful when doing multiple tests.

Configuring let's encrypt (deprecated)

Important

Ensure you have password login available to the cluster. Let's encrypt will replace the API certificate in addition to the certificates to user with routes.

Trustee (guest agents) requires that Trustee uses a Mozilla trusted CA issued certificate, or a specific certificate which is known in advance. Today the pattern uses specific self signed certs. Let's encrypt was an option for getting a trusted certificate onto OpenShift's routes, and therefore Trustee. Ths functionality will be removed at a later date.

If you need a Let's Encrypt certificate to be issued the letsencrypt application configuration needs to be changed as below.

    ---
    # Default configuration, safe for ARO
    letsencrypt:
      name: letsencrypt
      namespace: letsencrypt
      project: hub
      path: charts/all/letsencrypt
      # Default to 'safe' for ARO
      overrides:
      - name: letsencrypt.enabled
        value: false
    ---
    # Explicitly correct configuration for enabling let's encrypt
    letsencrypt:
      name: letsencrypt
      namespace: letsencrypt
      project: hub
      path: charts/all/letsencrypt
      overrides:
      - name: letsencrypt.enabled
        value: true  

Warning

Configuration changes are only effective once committed and pushed to your remote repository.

Installing onto a cluster

Once you configuration is pushed (if required) ./pattern.sh make install to provision a cluster.

Tip

The branch and default origin you have checked-out in your local repository is used to determine what ArgoCD and the patterns operator should reconcile against. Typical choices are to use the main for your fork.

Cluster setup (if not already setup)

Single cluster install on an OCP cluster on azure using Red Hat Demo Platform

Red Hat a demo platform. This allows easy access for Red Hat associates and partners to ephemeral cloud resources. The pattern is known to work with this setup.

1. Get the openshift installer
   1. NOTE: openshift installer must be updated regularly if you want to automatically provision the latest versions of OCP
2. Get access to an Azure Subscription Based Blank Open Environment.
3. Import the required azure environmental variables (see code block below)
4. Ensure certificates are configured (via let's encrypt or do so manually)
5. Run the wrapper install script
   1. bash ./rhdp/wrapper.sh azure-region-code
   2. Where azure region code is eastasia, useast2 etc.
6. You should be done
   1. You may need to recreate the hello world peer-pods depending on timeouts.

    export GUID=
    export CLIENT_ID=
    export PASSWORD=
    export TENANT=
    export SUBSCRIPTION=
    export RESOURCEGROUP=

Single cluster install on plain old azure not using Red Hat Demo Platform

Tip

Don't use the default node sizes.. increase the node sizes such as below

1. Login to console.redhat.com
2. Get the openshift installer
3. Login to azure locally.
4. openshift-install create install-config
   1. Select azure
   2. For Red Hatter's and partners using RHDP make sure you select the same region for your account that you selected in RHDP
5. Change worker machine type e.g. change type: Standard_D4s_v5 to type: Standard_D8s_v5 or similar based on your needs.
6. mkdir ./ocp-install && mv openshift-install.yaml ./ocp-install
7. openshift-install create cluster --dir=./ocp-install
8. Once installed:
   1. Login to oc
   2. Configure Let's Encrypt (if required)
   3. ./pattern.sh make install

Multi cluster setup

TBD