Confidential managed services

note

Not every Codesphere instance offers confidential compute. Ask your Codesphere administrator whether confidential compute is available on your instance. See Prerequisites.

Managed services such as databases often hold your most sensitive data. In confidential mode, each service instance runs in a confidential micro-VM, stores its data on encrypted volumes and communicates through the service mesh. Its secrets come from the trustee service vault, so Codesphere never sees them.

Prerequisites

• You have a trustee service and its address.
• You have requested a workload ID from the trustee provider. See Request a confidential workload.
• The secrets of the managed service are stored in the trustee service vault. See Manage secrets in the trustee service vault.
• The provider supports confidential mode. See Check provider support.

Differences from regular managed services

• Secrets come from the trustee service vault. You do not enter secrets when you create the service. You enter vault paths instead, and the service reads the values from the trustee service vault after attestation. Codesphere does not store, show or change them.
• Only services of the same workload can connect. A confidential managed service only accepts connections from confidential services with the same workload ID in the same resource group, for example the services of a confidential landscape.
• Confidential mode is fixed at creation. You cannot turn an existing service into a confidential one or back. The workload ID and trustee service address cannot be changed either. To switch, create a new service and migrate your data manually, for example by exporting it from the old service and importing it into the new one.
• Slower startup and more memory. Each instance boots a micro-VM and passes attestation before it starts. See Limitations and gotchas.

Check provider support

Currently, these providers can be used confidentially:

• PostgreSQL supports confidential mode.
• Object storage (S3) has no confidential mode, but you can keep your data confidential by encrypting it. See Object storage (S3).

To check a provider, open its details page by clicking Start setup on its card in the catalog. Providers that support confidential mode list Confidential Compute under their capabilities.

In the API, the /managed-services/providers endpoint returns the capabilities of each provider. Providers that support confidential mode have confidentialCompute: true.

Object storage (S3)

Object storage has no confidential mode. Buckets are stored outside the confidential micro-VMs. To keep their content confidential, encrypt it with a key that only your confidential workload knows:

1. Store the key in the trustee service vault, for example as encryptionKey (openssl rand 32 | base64).
2. Read it in your service, for example with ${{ vault.encryptionKey }}.
3. Use the key with one of the methods below.

The bucket's access and secret keys don't need to be in the vault. Without the encryption key they only give access to encrypted data. If you lose the key, your data can't be recovered.

Server-side encryption with customer-provided keys (SSE-C): The client sends the key with every request. The object storage gateway runs in confidential pods, encrypts the object there before storing it and doesn't keep the key. It works with any S3 client that supports SSE-C. SSE-C requires the HTTPS endpoint https://rgw-load-balancer.rook-ceph.svc.cluster.local.

aws s3 cp report.pdf s3://my-bucket/ \
  --endpoint-url https://rgw-load-balancer.rook-ceph.svc.cluster.local \
  --sse-c AES256 --sse-c-key fileb://<(echo "$ENCRYPTION_KEY" | base64 -d)

Reading the object requires the same --sse-c flags.

Client-side encryption (CSE): The client encrypts the data before uploading it, so the object storage only ever sees encrypted data. Only clients that know the encryption format can read it. For example, with an rclone crypt remote on top of an S3 remote named s3:

rclone config create secure crypt remote s3:my-bucket \
  password "$(rclone obscure "$ENCRYPTION_KEY")"
rclone copy ./data secure:

Creating a confidential managed service

A confidential managed service is mostly created like a regular one. The difference is in how secrets are handled. You store them in the trustee service vault, not in Codesphere. Instead of entering secret values when you create the service, you enter the vault paths that point to them.

UI

Create the service as described in Deploying services, with these changes:

1. Under Advanced Settings, turn on Confidential Compute.
2. Enter the workload ID in vHSM Workload ID.
3. Enter the address of the trustee service in vHSM Address.
4. Enter the secrets' vault paths.

API

Create the service with the POST /managed-services request described in Deploying services, with these changes:

{
  "secrets": {
    "userPassword": "${{ vault['pg/userPassword'] }}",
    "superuserPassword": "${{ vault['pg/superuserPassword'] }}"
  },
  "confidentialWorkloadId": "00000000-0000-0000-0000-000000000000",
  "vhsmAddress": "https://trustee.example.com"
}

• confidentialWorkloadId (string, UUID): The workload ID from your trustee provider. Setting it turns on confidential mode.
• vhsmAddress (string, HTTPS URL): The address of the trustee service. If you leave it out, your Codesphere instance's default trustee service is used.
• secrets (object): The vault paths of the service's secrets in the trustee service vault. Codesphere does not resolve them. The service reads the values from the trustee service vault after attestation.

Managed services in confidential landscapes

Managed services defined in a landscape are created in confidential mode automatically when the landscape runs in a confidential workspace. They use the same workload ID and trustee service as the workspace. There is no separate setting in the ci.yml.

As with standalone confidential managed services, you provide the vault paths of the secrets. The service reads the values from the trustee service vault after attestation.