⚙️
Morphisms: Confidential Serverless Containers
  • Introduction
  • Preliminaries
    • What is Confidential Computing?
      • Threat Model
      • Intel SGX
        • Threat Model
        • Memory Layout
        • Memory encryption
        • Enclave Lifecycle
        • Entering and Exiting an Enclave
        • Measurement
        • Certificate
        • Key Derivation
        • Attestation
        • Gramine
        • SGX2
        • Secret Key Provisioning
      • AMD SEV-SNP
        • Encrypted CPU Registers
        • Memory encryption
        • Secure Nested Paging
        • Virtual Machine Privilege Levels (VMPL's)
        • Cryptographic Keys
        • Secret Key Provisioning
        • Guest Deployment
    • Serverless (FaaS)
      • Knative
  • Confidential Serverless Containers
    • Introduction
    • Intel SGX
      • Threat Model
      • Remote attestation verification
      • Secure Storage
        • HashiCorp's Vault
      • Architecture
        • Confidential Knative
        • Certificates
        • Session Management
      • Confidential Container Configuration
    • AMD SEV-SNP
      • Threat Model
      • Architecture
        • Network communication
        • KMS
        • Updates
        • Key rotation
      • Design Decision
  • Benchmarks
    • Hardware
    • Results
    • Architecture Comparison
  • Getting Started
    • FAQ
    • Intel SGX
    • AMD SEV-SNP
  • Glossary
    • SGX Glossary
    • AMD SEV-SNP Glossary
Powered by GitBook
On this page
  1. Confidential Serverless Containers
  2. AMD SEV-SNP
  3. Architecture

KMS

PreviousNetwork communicationNextUpdates

Last updated 1 year ago

It is possible to use Istio to create access policies for secrets. This only works if secrets are requested from a specific path, for example https://mykms.com/get/my-secret, where my-secret is the secret. The downside of this is that it makes it a little harder for a cloud customer to manage. Now the cloud customer has to create a secret in the KMS, create a policy for the secret in the KMS, and in Istio to grant authorized access to it. Vault, for example, strictly prohibits access to secrets unless there is a policy that allows the user to access them. Therefore, the Vault would need a policy as well. To make it easier for an administrator, the Vault does not use Istio mTLS. Istio enables mTLS for a specific namespace or for all namespaces. By moving the KMS to a different namespace, the KMS automatically does not have Istio mTLS enabled. In order for the KMS to know what secrets a particular client certificate is allowed to access, all client certificates must be stored in the KMS with an authorization policy. In this context, the client certificate created for the Envoy proxies must be stored. Depending on the application, it may also make sense to use Istio Destination Routes. These allow custom client certificates to be attached to a specific Envoy proxy. The advantage here is that the certificate is known before the serverless container is started, so the vault can be preconfigured. On the other hand, more trust must be placed in the etcd store, since the client certificates must be stored there.

The figure below, gives an overview of in-cluster communication, here the activator is abstracted. The activator also has an envoy injected for in-cluster communication and can run in any of the cVM's where the serverless containers are running.

The Istio gateway should use a wildcard certificate to terminate the TLS connection to the client and forward the request via Istio mutual TLS to the next Knative component in the current request path. This eliminates the session management required by the SGX architecture to improve performance, as the client always connects to the same gateway over TLS, improving performance.

AMD SEV-SNP Architecture