Skip to content

Workload Confidentiality

Workload Confidentiality builds upon Platform Attestation to protect data in virtual machine and container images. At its core, this feature is about allowing an image owner to set policies that define the conditions under which their image will be allowed to run; if the policy conditions are met, the decryption key will be provided, and if the conditions are not met, the image will remain encrypted and inaccessible. This provides a level of enforcement beyond integration with orchestrators, and protects sensitive data when the image is at rest.

Workload Encryption relies on Platform Attestation to define the security attributes of hosts. When a protected image is launched, the Workload Agent on the host launching the VM or container image will detect the attempt (using either Libvirt hooks for VMs, or as a function of CRI-O in the case of containers) and use the Image ID to find the Image Flavor on the Workload Service. The Workload Service will retrieve the current trust report for the host launching the image, and use that report to make a key retrieval request to the key transfer URL retrieved from the image flavor. The key transfer URL refers to the URL to the image owner’s Key Broker Service, along with the ID of the key needed.

In a typical production deployment, a Cloud Service Provider would enable Intel® SecL-DC security controls by installing the Intel® SecL-DC applications (with the exception of the Key Broker and Workload Policy Manager), and configuring each workload host to be Trusted (as per the Platform Integrity Attestation use case).

The owner of the workload image(s) to be protected (for example, the end customer of the CSP) must install a Key Broker Service (which must be available for network communication from the Workload Service hosted on the CSP), the Workload Policy Manager, and their own Authentication and Authorization Service and Certificate Management Service (these will manage authentication and certificates for the KBS and WPM).

Any number of image owner customers with their own unique KBS/WPM/AAS/CMS deployments may protect images that can be run by a single CSP deployment.

The image owner will use the WPM to encrypt any image(s) to be protected; the WPM will automatically create a new image encryption key using the KBS, and will output the encrypted image and an Image Flavor. The image owner can then upload the encrypted image to the CSP’s image storage service, and then upload the Image Flavor to the CSP-hosted WLS.

image-encryption

When a compute host at the CSP attempts to launch a protected image, the WLA on the host will detect the launch request, and will issue a key transfer request to the WLS. The WLS will use the image ID to retrieve the Image Flavor, which contains the key retrieval URL for that image. This URL is hosted on the KBS of the image owner (which is why the KBS must be available to network requests from the WLS). The WLS will access the HVS to retrieve the current Platform Integrity Attestation report for the host, and will use this report to make a key transfer request to the KBS at the key transfer URL.

The KBS will receive the request, verify that the Platform Integrity Attestation report is signed using a known SAML signing key (verifying that the report comes from a known and trusted HVS), and will then verify that the report shows that the host is trusted.

If these requirements are met, the KBS will use the host’s Binding Key (the public half of an asymmetric keypair generated by the host’s TPM and included in the attestation report) as a Key Encryption Key to seal the Image Encryption Key to the TPM of the host that was attested.

When the host receives the response to the key request, it will unseal the Image Encryption Key using its TPM. Because the Key Encryption Key is unique to this host’s TPM, only the actual host that was attested will be able to gain access to the image.

With the Image Encryption Key, the host’s WLA will create the appropriate encrypted volume(s) for the image and begin the launch as normal.

The WLA does not retain the key on disk; if/when the host is rebooted or the WLA is restarted, restarting the workloads based on protected images will trigger new key requests based on new Platform Integrity Attestation reports. In this way, if a host is compromised in a method detectable by the Platform Integrity feature, protected images will be unable to launch on this server.

workload-decryption

Virtual Machine Confidentiality

Prerequisites

To enable Virtual Machine Confidentiality, the following Intel® SecL-DC components must be installed and available:

  • Authentication and Authorization Service

  • Certificate Management Service

  • Key Broker Service

  • Host Verification Service

  • Workload Service

  • Trust Agent + Workload Agent (on each virtualization host)

  • Workload Policy Manager

See the Installation subsection on Recommended Service Layout for recommendations on how/where to install each service.

It is strongly recommended to use a VM orchestration solution (for example, OpenStack) with the Intel® SecL-DC Integration Hub to schedule encrypted workloads on compute hosts that have already been pre-checked for their Platform Integrity status. See the Platform Integrity Attestation subsection on Integration with OpenStack for an example.

You will need at least one QCOW2-format virtual machine image (for quick testing purposes, a very small minimal premade image like CirrOS is recommended; a good place to look for testing images is the OpenStack Image Guide found here: https://docs.openstack.org/image-guide/obtain-images.html).

One or more hypervisor compute nodes running QEMU/KVM is required. Each of these nodes must have the Intel® SecL-DC Trust Agent and Workload Agent installed, and they must be registered with the Verification Service. Each of these servers should show as trusted see the Platform Integrity Attestation section for details. You should have Flavors that match the system configuration for these hosts, and attestation reports should show all Flavor parts as trusted=true Hosts that are not trusted (including servers where there is no trust status, like hosts with no Trust Agent) will fail to launch any encrypted workloads.

Workflow

Encrypting images

wpm create-image-flavor -l <user-friendly unique label> -i <path to image file> -e <output path and filename for encrypted image> -o <output path for JSON image flavor>`

After generating the encrypted image with the WPM, the encrypted image can be uploaded to the Image Storage service of choice (for example, OpenStack Glance). Note that the ID of the image in this Image Storage service must be retained and used for the next steps.

Uploading the Image Flavor

POST https://<Workload Service IP or Hostname>:5000/wls/flavors
Authorization: Bearer <token>

{<Image Flavor content from WPM output>}

Use the above API request to upload the Image Flavor to the WLS. The Image Flavor will tell other Intel® SecL-DC components the Key Transfer URL for this image.

Creating the Image Flavor to Image ID Association

The WLS needs to know the ID of the image as it exists in the image storage service used by the CSP (for example, OpenStack Glance). Use the below API request to create an association between the Image Flavor created in the previous step and the image ID.

POST https://<Workload Service IP or Hostname>:5000/wls/images
Authorization: Bearer <token>

{
    "id": "<image ID on image storage>",
    "flavor_ids": ["<Image Flavor ID>"]
}

Launching Encrypted VMs

Instances of the protected images can now be launched as normal. Encrypted images will only be accessible on hosts with a Platform Integrity Attestation report showing the host is trusted.

If the VM is launched on a host that is not trusted, the launch will fail, as the decryption key will not be provided.

Container Confidentiality

Container Confidentiality with Cri-o and Skopeo

Prerequisites

Container Confidentiality with Cri-o and Skopeo requires modified versions of both Cri-o and Skopeo. Both of these are automatically built with the Intel SecL build scripts, and can be found here after the script has executed:

isecl/cc-crio/binaries/

Skopeo

cp isecl/cc-crio/binaries/skopeo /usr/bin/skopeo
  • Add the following to the crio.service definition to always start Cri-o with the Intel SecL policy parameters enabled:
vi /usr/local/lib/systemd/system/crio.service
ExecStart=/usr/local/bin/crio \
          $CRIO_CONFIG_OPTIONS \
          $CRIO_RUNTIME_OPTIONS \
          $CRIO_STORAGE_OPTIONS \
          $CRIO_NETWORK_OPTIONS \
          $CRIO_METRICS_OPTIONS \
          --decryption-secl-parameters secl:enabled

Cri-o 1.17

cp isecl/cc-crio/binaries/crio /usr/bin/crio

$ VERSION="v1.17.0"
$ wget https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz
$ sudo tar zxvf crictl-$VERSION-linux-amd64.tar.gz -C /usr/local/bin
$ rm -f crictl-$VERSION-linux-amd64.tar.gz

  • Kubernetes must be configured to use Cri-o and Skopeo

  • Platform Integrity Attestation must be configured for the physical Kubernetes Worker Nodes.

  • This includes, at minimum, the CMS; AAS; HVS; KBS; WPM; and the Trust Agent must be installed on each Worker Node. See the Installation section for details installing these services.

  • Each Kubernetes Worker Node should be Trusted in the attestation reports generated by the HVS.

  • Only physical Worker Nodes are supported at this time.

Workflow

Skopeo Commands
skopeo copy source-image destination-image

 Options:

--encryption-key [secl:asset_tag|keyfile] Specifies the encryption protocol. When using secl protocol, provide either "any" or an asset tag in the form "at_key:at_value"; only one asset tag can be used at this time. Alternatively, a specific key can be provided to be used for encryption.

--decryption-key [secl:enabled|keyfile] specifies the decryption Alternatively, a specific key can be provided to be used for decryption. This flag can be repeated if an image requires more than one key to be decrypted.

See https://github.com/lumjjb/skopeo/blob/sample_integration/docs/skopeo-copy.1.md for more details.

Examples

Copy a container image from a registry to a local server:

$ skopeo copy docker://docker.io/library/nginx:latest oci:nginx_local

To encrypt an image (this will allow the image to run only on Trusted platforms):

$ skopeo copy --encryption-key secl:any oci:nginx_local oci:nginx_secl_enc

To encrypt an image with an Asset Tag (this will allow the image to run only on Trusted platforms with the specified Asset tag):

$ skopeo copy --encryption-key secl:asset_tag_key:asset_tag_value oci:nginx_local oci:nginx_secl_enc_w_at

To decrypt an image:

$ skopeo copy --decryption-key secl:enabled oci:nginx_secl_enc oci:nginx_secl_dec

To copy an encrypted image without decryption:

$ skopeo copy oci:nginx_secl_enc oci:nginx_secl_enc_copy

To copy a local image to a remote registry:

$ skopeo copy oci:nginx_secl_enc docker://10.80.245.116/nginx_secl_enc:latest
Prepare an Image

Convert the image to an OCI image using Skopeo:

$ skopeo copy docker-daemon:custom-image:latest oci:custom-image:latest

Encrypt the image using Skopeo copy command

$ skopeo copy --encryption-key secl:any oci:custom-image:latest oci:custom-image:enc

Push the image to a registry:

$ skopeo copy oci:custom-image:enc docker://Registry.server.com:5000/custom-image:enc

Alternatively, encrypt the image and push it to a registry in a single step:

$ skopeo copy --encryption-key secl:any oci:custom-image:latest docker://registry.server.com:5000/custom-image:enc
Pulling and Encrypting a Container Image

Skopeo can be used to pull a container image from an external registry (a private Docker registry is used in the examples below). This image may be encrypted already, but if you wish to pull an image for encryption, it must be in plaintext format. Skopeo has a wrapper that can interact with the Workload Policy Manager. When trying to encrypt an image, Skopeo calls the WPM CLI fetch-key command. In the command, the KBS is called in order to create a new key. The return from the KBS includes the key retrieval URL, which is used when trying to decrypt. After the key is returned to the WPM, the WPM passes the key back to Skopeo. Skopeo uses the key to encrypt the image layer by layer as well as associate the encrypted image with the key's URL. Skopeo then uploads the encrypted image to a remote container registry.

The modified Cri-o and wrapper will modify the Cri-o commands to allow Intel SecL policies to be utilized.

Launching an Encrypted Container Image

Cri-o allows for pulling and decryption of an encrypted container image from a container registry. When trying to pull and decrypt a container image, Cri-o has a hook that calls into the Workload Agent (WLA). The WLA will call into the Workload Service (WLS) and pass it the key URL associated with the encrypted image as well as the host's hardware UUID. These two serve as input to /keys endpoint of the WLS. The WLS initializes a HVS client in order to retrieve the host SAML report and then validates the report. If the host is trusted, the WLS will attempt to get the key. First, it will check if it's been cached alredy. If not, it will initialize a KBS client. The WLS uses this client to retrieve the key from the KBS. If the key is retrieved, it will be cached in the WLS temporarily so that the WLS will not need to requery the KBS if attempting to decrypt with the same key. The key is then passed back to the WLA as the return of the WLS's keys API. Finally, the key is returned to Cri-o, which uses the key to decrypt the container image layer by layer.

Containers of the protected images can now be launched as normal using Kubernetes pods and deployments. Encrypted images will only be accessible on hosts with a Platform Integrity Attestation report showing the host is trusted. If the Crio Container is launched on a host that is not trusted, the launch will fail, as the decryption key will not be provided.

Back to top