trustee-chart/values.yaml at main · validatedpatterns/trustee-chart · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
---
# Secret store configuration
# Default configuration is vault
secretStore:
  name: "vault-backend"
  kind: "ClusterSecretStore"


global:
  secretStore:
    # Secret store backend, typically overridden by values-global.yaml
    backend: ""
  # must be global as needs to be propagated to ansible playbooks.
  # SHOULD be set in values-global.yaml
  coco:
    securityPolicy: secret/data/hub/securityPolicyConfig
    securityPolicyFlavour: "insecure" # insecure, signed or reject is expected.
    attestationStatus: secret/data/hub/attestationStatus
    secured: false # true or false. If true, the cluster will be secured. If false, the cluster will be insecure.

# KBS (Key Broker Service) configuration
kbs:
  # Security policy is an expected secret and is required to be pushed into the KBS
  # presumes security policy flavour is signed
  cosignKeys: secret/data/hub/coSignKeys

  # Dynamic secret resources list - add new secrets here
  # Each entry generates an ESO and gets added to kbsSecretResources
  # requires a name of the secret and a key to retrieve using ESO, typically from vault.
  secretResources:
    # Example:
    - name: "kbsres1"
      key: "secret/data/hub/kbsres1"
    - name: "passphrase"
      key: "secret/data/hub/passphrase"
  # Pre-existing secrets to add to kbsSecretResources without creating
  # ExternalSecrets. Use this for secrets that are created outside the
  # Vault/ESO flow (e.g. by imperative jobs, cert-manager, or other
  # controllers). Only the secret name is needed; the secret must already
  # exist in the trustee-operator-system namespace.
  extraSecrets:
    - credential

  # Number of HTTP worker threads for the KBS server.
  # If unset, the KBS binary defaults to one worker per logical CPU core,
  # which can cause "too many open files" crashes on high-core-count systems
  # where the container's nofile ulimit is lower than the worker count.
  # Set this to a reasonable value (e.g., 4-8) on systems with many cores.
  # workerCount: 4

  # NVIDIA GPU confidential computing configuration
  gpu:
    enabled: false

  # Intel TDX (Trust Domain Extensions) configuration
  tdx:
    # Enable TDX attestation support
    enabled: false
    # PCCS collateral service URL for quote verification
    # For Azure: Use https://global.acccache.azure.net/sgx/certification/v4/
    # For bare metal/Intel: Use https://api.trustedservices.intel.com/sgx/certification/v4/
    collateralService: "https://api.trustedservices.intel.com/sgx/certification/v4/"

  # Bare metal attestation configuration
  # Enables firmware reference value collection and enforcement
  baremetal:
    # Enable bare metal firmware reference values (Intel TDX / AMD SEV-SNP)
    # When enabled, creates ExternalSecret to pull firmware measurements from Vault
    # Requires firmware values pushed to secret/data/hub/firmwareReferenceValues
    # See docs/firmware-reference-values.md in coco-pattern for collection workflow
    enabled: false

  # Azure SEV-SNP platform configuration reference values
  # These are used by the attestation policy to verify the CVM configuration.
  # The values below are defaults for Azure DCasv5-series VMs (AMD SEV-SNP).
  #
  # These are Azure platform constants that describe the SEV-SNP policy
  # enforced by Azure for confidential VMs. They may vary by:
  #
  #   VM Series       | SMT | TSME | ABI Minor | Notes
  #   ----------------|-----|------|-----------|------
  #   DCasv5 (Genoa)  | true| true | 31        | Standard CoCo peer-pod VMs
  #   DCadsv5 (Genoa) | true| true | 31        | With local NVMe
  #   ECasv5 (Genoa)  | true| true | 31        | Memory-optimized
  #   DCesv5 (Milan)  | true| true | 31        | Earlier generation, may differ
  #
  # The SNP launch measurement (snpLaunchMeasurement) is a hash of the
  # Azure UEFI firmware + vTPM initial state. It is static per Azure CVM
  # firmware generation but will change when Azure updates the firmware.
  # It is NOT derived from the workload image — it is an Azure platform
  # constant for the VM type.
  #
  # If attestation fails on configuration/executables claims, check the
  # trustee logs for the actual values reported by the VM and update these.
  azure:
    snpLaunchMeasurement: "qnydpVwThuWxZTsSWXi+2ns/laha6w+d2723g84FaijJ0CHaI5w0pYw6ZXZUJw7v"
    smtEnabled: "true"
    tsmeEnabled: "true"
    abiMajor: "0"
    abiMinor: "31"
    singleSocket: "false"
    smtAllowed: "true"

  # Resource policy configuration
  resourcePolicy:
    # Enforce hardware trust claims in resource policy
    # When true: requires hardware claim >= 2 (affirming range)
    # When false: allows resource access even if hardware claim fails
    # Note: For SNP, hardware enforcement requires TCB reference values
    # (tcb_bootloader, tcb_microcode, tcb_snp, tcb_tee) in RVPS
    enforceHardware: true

# Attestation token certificate configuration
# Used when secretStore.backend is "none" (cert-manager generates certs)
attestation:
  commonName: "kbs-trustee-operator-system"
  organization: "Red Hat"