DOCSEARCHbyAlgolia
Submit Docs

Contrast

repository·main·Indexed 43 days ago

https://github.com/edgelesssys/contrast

A platform for running confidential container deployments on Kubernetes at scale using hardware-based isolation via Kata Containers. It features a central Coordinator for manifest management, workload verification, and state management, alongside a node installer for configuring the contrast-cc-isolation runtime class.

Tokens
104.1K
Snippets
256
Records
443
Agent score
55%

What's inside Contrast

  1. What is Contrast?

    main

    Contrast is a tool that makes Kubernetes deployments confidential by running workloads securely within confidential computing environments. It is built upon the open-source Kata Containers project.

    Contrast provides confidential containers: Kubernetes pods executed within confidential micro-VMs. This provides strong, hardware-based isolation from the surrounding environment. Because it uses standard containers, you can use your existing containers without modification via a lift-and-shift approach.

  2. Overview of the Contrast node installer

    main

    The Contrast node installer is a program designed to run as a daemonset on every CC-enabled node within a Kubernetes cluster.

    Operational Workflow:

    1. Mounting: It requires the host filesystem of the node to be mounted under /host.
    2. Configuration: On startup, it reads a configuration file located at $CONFIG_DIR/contrast-node-install.json.
    3. Installation: It installs binary artifacts onto the host filesystem based on the configuration.
    4. Runtime Setup: After installing binaries, it installs and patches configuration files for the Contrast runtime class contrast-cc-isolation and restarts containerd to apply changes.

  3. Overview of Contrast

    main

    Contrast is a platform for running confidential container deployments on Kubernetes at scale. It is built upon Kata Containers and implements the confidential containers concept.

    Key characteristics include:

    • Confidential Micro-VMs: Kubernetes pods are executed inside confidential micro-VMs, providing hardware-based isolation.
    • Lift-and-Shift: Works with unmodified containers, allowing existing workloads to be moved to a confidential environment without code changes.
    • Reduced TCB: Removes the infrastructure provider (datacenter employees, cloud admins, cluster admins, and malicious co-tenants) from the Trusted Computing Base (TCB).
    • Kubernetes Integration: Integrates with existing workflows, is compatible with managed Kubernetes, and can be installed as a day-2 operation.

  5. Create reproducible OCI images with Nix

    main

    The ociImageLayout package provides a set of Nix functions to create reproducible and cachable multi-layer OCI (Open Container Initiative) images. These images can be used directly by tools like podman or uploaded to a registry using crane push.

    The package is built around four primary components:

    1. ociImageLayout: The top-level function used to create an OCI image directory layout.
    2. ociImageManifest: Defines the image manifest, which links a configuration to a set of layers.
    3. ociImageConfig: Defines the image configuration (entrypoint, arguments, architecture, OS, environment variables, etc.).
    4. ociLayerTar: Represents an individual filesystem changeset (layer). It accepts a list of files, mapping source paths to target destinations within the image.
    ociImageLayout {
  manifests = [ 
    # ... manifests containing ociImageManifest ... 
  ];
}

  7. Use the Contrast SDK for programmatic interaction

    main

    The Contrast SDK provides a way to write programs that interact with a Contrast deployment programmatically, offering an alternative to using the Contrast CLI.

    Caution: This SDK is currently under active development and is not considered stable. Users should expect breaking changes with new minor versions.

  10. CI integration for Contrast documentation

    main

    The Contrast documentation deployment pipeline is managed via GitHub Actions:

    • PR Previews: When a Pull Request is created, the docs_publish workflow builds the site and pushes it to the /pr-preview directory of the gh-pages branch.
    • Main Branch Publishing: When changes are pushed to main, the docs_publish workflow builds the site and pushes it to the gh-pages branch.
    • Deployment: Actual deployment to the web is handled by GitHub's controlled action.
    • Versioning: Release versioning is managed by the project's release workflow.

  11. What is the Contrast service mesh and how does it work?

    main

    The Contrast service mesh secures workload communication by automatically wrapping network traffic in mutual TLS (mTLS) connections. It uses certificates from the Coordinator's PKI for endpoint verification.

    When enabled via workload annotations, the Contrast CLI injects a service mesh sidecar container during the contrast generate step. This sidecar container performs two main tasks:

    1. Sets up iptables rules based on your configuration.
    2. Starts Envoy for TLS origination and termination.

    Startup Enforcement: To prevent unencrypted traffic during container startup, a systemd unit inside the podVM creates a 'deny all' rule for incoming connections. This rule is active before any containers start. The kata-agent only begins after this unit successfully exits. You can disable this enforcement by omitting service mesh annotations or using the --skip-service-mesh flag with the CLI.

  12. What is the Contrast Coordinator?

    main

    The Contrast Coordinator is the central remote attestation service for a Contrast deployment. It runs inside a confidential container within your cluster and serves several critical roles:

    • Remote Attestation: It can be verified via remote attestation, providing a single attestation statement for your entire deployment when combined with the manifest.
    • Topology Enforcement: It uses a manifest (a configuration file of reference attestation values) to verify the identity and integrity of all confidential pods in the deployment.
    • Certificate Authority (CA): It acts as a root CA, issuing certificates to workload pods during the attestation procedure so they can establish secure, encrypted communication channels.
    • Scaling Support: It transparently verifies and certificates new instances as your application scales.

    To verify the integrity of a distributed app, a third party can use the Coordinator's remote attestation statement and the manifest to assure stakeholders of the app's identity and integrity.