Delen via

Vertrouwelijke containers implementeren in een ARO-cluster (Azure Red Hat OpenShift) (preview)

  • Artikel

In dit artikel worden de stappen beschreven die nodig zijn voor het implementeren van vertrouwelijke containers voor een ARO-cluster. Dit proces omvat twee hoofdonderdelen en meerdere stappen:

Implementeer eerst OpenShift Sandboxed Containers, met inbegrip van de volgende stappen:

  1. Installeer de operator OpenShift Sandboxed Containers.

  2. Maak het geheim van de peerpods.

  3. Maak de configuratietoewijzing voor peer-pods.

  4. Maak het Azure-geheim.

Nadat u OpenShift Sandboxed Containers hebt geïmplementeerd, implementeert u Vertrouwelijke containers. Dit omvat de volgende stappen:

  1. Installeer de beheerder.

  2. Maak de route voor de beheerder.

  3. Schakel de functiepoort Vertrouwelijke containers in.

  4. Werk de configuratietoewijzing voor peer-pods bij.

  5. Maak de aangepaste KataConfig-resource.

  6. Maak het verificatiegeheim van de beheerder.

  7. Maak de toewijzing van de beheerdersconfiguratie.

  8. Configureer de beheerder.

  9. Maak de aangepaste KbsConfig-resource.

  10. Controleer het attestation-proces.

Voordat u begint

Voordat u begint met het implementatieproces, moet u ervoor zorgen dat aan de volgende vereisten wordt voldaan:

  • Een bestaand ARO-cluster (versie 4.15 of hoger) met ten minste één werkknooppunt

  • Toegang tot het cluster met de cluster-admin rol

  • De OpenShift CLI geïnstalleerd

Belangrijk

Voor elke pod in een toepassing is er een een-op-een-toewijzing met een bijbehorende CVM (Confidential Virtual Machine). Dit betekent dat elke nieuwe pod een afzonderlijke CVM vereist, waardoor isolatie tussen pods wordt gegarandeerd.

Deel 1: OpenShift-sandbox-containers implementeren

De Operator voor OpenShift-sandbox-containers installeren

De operator voor sandbox-containers van OpenShift kan worden geïnstalleerd via de CLI of de OpenShift-webconsole.

  1. Maak een osc-namespace.yaml manifestbestand:

    apiVersion: v1
kind: Namespace
metadata:
    name: openshift-sandboxed-containers-operator

  2. Maak de naamruimte door de volgende opdracht uit te voeren:

    $ oc apply -f osc-namespace.yaml

  3. Maak een osc-operatorgroup.yaml manifestbestand:

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sandboxed-containers-operator-group
  namespace: openshift-sandboxed-containers-operator
spec:
  targetNamespaces:
  - openshift-sandboxed-containers-operator

  4. Maak de operatorgroep door de volgende opdracht uit te voeren

    $ oc apply -f osc-operatorgroup.yaml

  5. Maak een osc-subscription.yaml manifestbestand:

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sandboxed-containers-operator
  namespace: openshift-sandboxed-containers-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: sandboxed-containers-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: sandboxed-containers-operator.v1.7.0

  6. Maak het abonnement door de volgende opdracht uit te voeren:

    $ oc apply -f osc-subscription.yaml

  7. Controleer of de operator juist is geïnstalleerd door de volgende opdracht uit te voeren:

    $ oc get csv -n openshift-sandboxed-containers-operator

    Notitie

    Het uitvoeren van deze opdracht kan enkele minuten in beslag nemen.

  8. Bekijk het proces door de volgende opdracht uit te voeren:

    $ watch oc get csv -n openshift-sandboxed-containers-operator

    Voorbeelduitvoer

    NAME                             DISPLAY                                  VERSION    REPLACES     PHASE
openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.7.0      1.6.0        Succeeded

Het geheim van peerpods maken

U moet het peer-podsgeheim maken voor OpenShift-containers in de sandbox. Het geheim slaat referenties op voor het maken van de vm-installatiekopieën (pod) van de pod en peerpod-exemplaren van de pod.

Standaard maakt de openShift-containeroperator het geheim op basis van de referenties die worden gebruikt om het cluster te maken. U kunt echter handmatig een geheim maken dat gebruikmaakt van verschillende referenties.

  1. Haal de Azure-abonnements-id op door de volgende opdracht uit te voeren:

    $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \
  -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""

  2. Genereer de RBAC-inhoud (op rollen gebaseerd toegangsbeheer) door de volgende opdracht uit te voeren:

    $ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID \
      --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"

    Voorbeelduitvoer

    {
      "client_id": `AZURE_CLIENT_ID`,
      "client_secret": `AZURE_CLIENT_SECRET`,
      "tenant_id": `AZURE_TENANT_ID`
    }

  3. Noteer de RBAC-uitvoer die moet worden gebruikt in het geheime object.

  4. Maak een peer-pods-secret.yaml-manifestbestand volgens het volgende voorbeeld:

    apiVersion: v1
kind: Secret
metadata:
  name: peer-pods-secret
  namespace: openshift-sandboxed-containers-operator
type: Opaque
stringData:
  AZURE_CLIENT_ID: "<azure_client_id>"
  AZURE_CLIENT_SECRET: "<azure_client_secret>"
  AZURE_TENANT_ID: "<azure_tenant_id>"
  AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>"
    • Geef de AZURE_CLIENT_ID value op.
    • Geef de AZURE_CLIENT_SECRET value op.
    • Geef de AZURE_TENANT_ID value op.
    • Geef de AZURE_SUBSCRIPTION_ID value op.

  5. Maak het geheim door de volgende opdracht uit te voeren:

    $ oc apply -f peer-pods-secret.yaml

De configuratietoewijzing voor peer-pods maken

  1. Haal de volgende waarden op uit Azure:

    1. Haal de Azure-resourcegroep op en noteer deze:

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""

    2. Haal de Azure VNet-naam op en noteer deze:

      $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

      Deze waarde wordt gebruikt om de Azure-subnet-id op te halen.

    3. Haal de Azure-subnet-id op en noteer deze:

      $ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""

    4. Haal de id (NSG) van de Azure-netwerkbeveiligingsgroep (NSG) op en noteer deze:

      $ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""

    5. Haal de Azure-regio op en noteer deze:

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""

  2. Maak een peer-pods-cm.yaml-manifestbestand volgens het volgende voorbeeld:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "azure"
  VXLAN_PORT: "9000"
  AZURE_INSTANCE_SIZE: "Standard_B2als_v2"
  AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5"
  AZURE_SUBNET_ID: "<azure_subnet_id>"
  AZURE_NSG_ID: "<azure_nsg_id>"
  PROXY_TIMEOUT: "5m"
  AZURE_IMAGE_ID: "<azure_image_id>"
  AZURE_REGION: "<azure_region>"
  AZURE_RESOURCE_GROUP: "<azure_resource_group>"
  DISABLECVM: "true"
    • AZURE_INSTANCE_SIZE is de standaardinstelling als er geen instantiegrootte is gedefinieerd in de workload.
    • AZURE_INSTANCE_SIZES bevat alle instantiegrootten die u kunt opgeven bij het maken van de pod. Hiermee kunt u kleinere instantiegrootten definiëren voor workloads die minder geheugen nodig hebben en minder CPU's of grotere instantiegrootten voor grotere workloads.
    • Geef de AZURE_SUBNET_ID waarde op die u hebt opgehaald.
    • Geef de AZURE_NSG_ID waarde op die u hebt opgehaald.
    • AZURE_IMAGE_ID is optioneel. Deze waarde wordt standaard ingevuld wanneer u de aangepaste KataConfig-resource uitvoert met behulp van een Azure-installatiekopieën-id op basis van uw clusterreferenties. Als u uw eigen Azure-installatiekopieën maakt, geeft u de juiste installatiekopieën-id op.
    • Geef de AZURE_REGION waarde op die u hebt opgehaald.
    • Geef de AZURE_RESOURCE_GROUP waarde op die u hebt opgehaald.

  3. Maak de configuratietoewijzing door de volgende opdracht uit te voeren: $ oc apply -f peer-pods-cm.yaml

Het Azure-geheim maken

U moet een SSH-sleutelgeheim maken dat azure gebruikt om virtuele machines te maken.

  1. Genereer een SSH-sleutelpaar door de volgende opdracht uit te voeren:

    $ ssh-keygen -f ./id_rsa -N ""

  2. Maak het geheime object door de volgende opdracht uit te voeren:

    $ oc create secret generic ssh-key-secret \
      -n openshift-sandboxed-containers-operator \
      --from-file=id_rsa.pub=./id_rsa.pub

  3. Verwijder de SSH-sleutels die u hebt gemaakt:

    $ shred --remove id_rsa.pub id_rsa

Deel 2: Vertrouwelijke containers implementeren

De beheerder installeren

  1. Maak een trustee-namespace.yaml-manifestbestand:

    apiVersion: v1
kind: Namespace
metadata:
name: trustee-operator-system

  2. Maak de naamruimte trustee-operator-system door de volgende opdracht uit te voeren:

    $ oc apply -f trustee-namespace.yaml

  3. Maak een trustee-operatorgroup.yaml-manifestbestand:

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: trustee-operator-group
  namespace: trustee-operator-system
spec:
  targetNamespaces:
  - trustee-operator-system

  4. Maak de operatorgroep door de volgende opdracht uit te voeren:

    $ oc apply -f trustee-operatorgroup.yaml

  5. Maak een trustee-subscription.yaml-manifestbestand:

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: trustee-operator
  namespace: trustee-operator-system
spec:
  channel: stable
  installPlanApproval: Automatic
  name: trustee-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: trustee-operator.v0.1.0

  6. Maak het abonnement door de volgende opdracht uit te voeren:

    $ oc apply -f trustee-subscription.yaml

  7. Controleer of de operator juist is geïnstalleerd door de volgende opdracht uit te voeren:

    $ oc get csv -n trustee-operator-system

    Het uitvoeren van deze opdracht kan enkele minuten in beslag nemen.

  8. Bekijk het proces door de volgende opdracht uit te voeren:

    $ watch oc get csv -n trustee-operator-system

    Voorbeelduitvoer

    NAME                          DISPLAY                        PHASE
trustee-operator.v0.1.0       Trustee Operator  0.1.0        Succeeded

De route voor de beheerder maken

Maak een beveiligde route met edge TLS-beëindiging voor de beheerder. Extern inkomend verkeer bereikt de routerpods als HTTPS en geeft deze door aan de curatorpods als HTTP.

  1. Maak een edge-route door de volgende opdracht uit te voeren:

    $ oc create route edge --service=kbs-service --port kbs-port \
  -n trustee-operator-system

    Notitie

    Op dit moment wordt alleen een route met een geldig ca-ondertekend certificaat ondersteund. U kunt geen route gebruiken met een zelfondertekend certificaat.

  2. Stel de TRUSTEE_HOST variabele in door de volgende opdracht uit te voeren:

    $ TRUSTEE_HOST=$(oc get route -n trustee-operator-system kbs-service \
  -o jsonpath={.spec.host})

  3. Controleer de route door de volgende opdracht uit te voeren:

    $ echo $TRUSTEE_HOST

    Voorbeelduitvoerkbs-service-trustee-operator-system.apps.memvjias.eastus.aroapp.io

    Noteer deze waarde voor de configuratietoewijzing van peerpods.

De functiepoort Vertrouwelijke containers inschakelen

  1. Maak een cc-feature-gate.yaml manifestbestand:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: osc-feature-gates
  namespace: openshift-sandboxed-containers-operator
data:
  confidential: "true"

  2. Maak de configuratietoewijzing door de volgende opdracht uit te voeren:

    $ oc apply -f cc-feature-gate.yaml

De configuratietoewijzing voor peer-pods bijwerken

  1. Haal de volgende waarden op uit uw Azure-exemplaar:

    i. Haal de Azure-resourcegroep op en noteer deze:

    $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""

    ii. Haal de Azure VNet-naam op en noteer deze:

    $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

    Deze waarde wordt gebruikt om de Azure-subnet-id op te halen.

    iii. Haal de Azure-subnet-id op en noteer deze:

    $ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""

    iv. Haal de id (NSG) van de Azure-netwerkbeveiligingsgroep (NSG) op en noteer deze:

    $ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""

    v. Haal de Azure-regio op en noteer deze:

    $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""

  2. Maak een peer-pods-cm.yaml manifestbestand volgens het volgende voorbeeld:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "azure"
  VXLAN_PORT: "9000"
  AZURE_INSTANCE_SIZE: "Standard_DC2as_v5"
  AZURE_INSTANCE_SIZES: "Standard_DC2as_v5,Standard_DC4as_v5,Standard_DC8as_v5"
  AZURE_SUBNET_ID: "<azure_subnet_id>"
  AZURE_NSG_ID: "<azure_nsg_id>"
  PROXY_TIMEOUT: "5m"
  AZURE_IMAGE_ID: "<azure_image_id>"
  AZURE_REGION: "<azure_region>"
  AZURE_RESOURCE_GROUP: "<azure_resource_group>"
  DISABLECVM: "false"
  AA_KBC_PARAMS: "cc_kbc::https://${TRUSTEE_HOST}"
    • AZURE_INSTANCE_SIZE is de standaardinstelling als er geen instantiegrootte is gedefinieerd in de workload. Geef voor TDX 'Standard_EC4eds_v5' op.
    • AZURE_INSTANCE_SIZES bevat alle instantiegrootten die u kunt opgeven bij het maken van de pod. Hiermee kunt u kleinere instantiegrootten definiëren voor workloads die minder geheugen nodig hebben en minder CPU's of grotere instantiegrootten voor grotere workloads. Geef voor TDX 'Standard_EC4eds_v5, Standard_EC8eds_v5, Standard_EC16eds_v5' op.
    • Geef de AZURE_SUBNET_ID waarde op die u hebt opgehaald.
    • Geef de AZURE_NSG_ID waarde op die u hebt opgehaald.
    • AZURE_IMAGE_ID (Optioneel): Deze waarde wordt standaard ingevuld wanneer u de aangepaste KataConfig-resource uitvoert met behulp van een Azure-installatiekopieën-id op basis van uw clusterreferenties. Als u uw eigen Azure-installatiekopieën maakt, geeft u de juiste installatiekopieën-id op.
    • Geef de AZURE_REGION waarde op die u hebt opgehaald.
    • Geef de AZURE_RESOURCE_GROUP waarde op die u hebt opgehaald.
    • AA_KBC_PARAMS hiermee geeft u de hostnaam van de route van de beheerder.

  3. Maak de configuratietoewijzing door de volgende opdracht uit te voeren:

    $ oc apply -f peer-pods-cm.yaml

  4. Start de peerpodconfig-ctrl-caa-daemon daemon opnieuw op door de volgende opdracht uit te voeren:

    $ oc set env ds/peerpodconfig-ctrl-caa-daemon \
  -n openshift-sandboxed-containers-operator REBOOT="$(date)"

De aangepaste KataConfig-resource maken

  1. Maak een example-kataconfig.yaml manifestbestand volgens het volgende voorbeeld:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      enablePeerPods: true
      logLevel: info
    #  kataConfigPoolSelector:
    #    matchLabels:
    #      <label_key>: '<label_value>'

    Optioneel: Als u knooppuntlabels hebt toegepast om kata-remote te installeren op specifieke knooppunten, geeft u de sleutel en waarde op, bijvoorbeeld CC: 'true'.

  2. Maak de aangepaste KataConfig-resource door de volgende opdracht uit te voeren:

    $ oc apply -f example-kataconfig.yaml

    De nieuwe aangepaste KataConfig-resource wordt gemaakt en installeert kata-remote als runtimeklasse op de werkknooppunten.

    Notitie

    Wacht tot de kata-externe installatie is voltooid en de werkknooppunten opnieuw moeten worden opgestart voordat u de installatie controleert.

  3. Controleer de voortgang van de installatie door de volgende opdracht uit te voeren:

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    Wanneer de status van alle werkrollen onder kataNodes is geïnstalleerd en de voorwaarde InProgress Onwaar is zonder een reden op te geven, wordt de kata-remote op het cluster geïnstalleerd.

  4. Controleer de daemon die is ingesteld door de volgende opdracht uit te voeren:

    $ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon

  5. Controleer de runtimeklassen door de volgende opdracht uit te voeren:

    $ oc get runtimeclass

    Voorbeelduitvoer

    NAME             HANDLER         AGE
kata-remote      kata-remote     152m

Het verificatiegeheim van de beheerder maken

  1. Maak een persoonlijke sleutel door de volgende opdracht uit te voeren:

    $ openssl genpkey -algorithm ed25519 > privateKey

  2. Maak een openbare sleutel door de volgende opdracht uit te voeren:

    $ openssl pkey -in privateKey -pubout -out publicKey

  3. Maak een geheim door de volgende opdracht uit te voeren:

    $ oc create secret generic kbs-auth-public-key --from-file=publicKey -n trustee-operator-system

  4. Controleer het geheim door de volgende opdracht uit te voeren:

    $ oc get secret -n trustee-operator-system

De toewijzing van de beheerdersconfiguratie maken

  1. Maak een kbs-config-cm.yaml manifestbestand:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kbs-config-cm
  namespace: trustee-operator-system
data:
  kbs-config.json: |
    {
      "insecure_http" : true,
      "sockets": ["0.0.0.0:8080"],
      "auth_public_key": "/etc/auth-secret/publicKey",
      "attestation_token_config": {
        "attestation_token_type": "CoCo"
      },
      "repository_config": {
        "type": "LocalFs",
        "dir_path": "/opt/confidential-containers/kbs/repository"
      },
      "as_config": {
        "work_dir": "/opt/confidential-containers/attestation-service",
        "policy_engine": "opa",
        "attestation_token_broker": "Simple",
          "attestation_token_config": {
          "duration_min": 5
          },
        "rvps_config": {
          "store_type": "LocalJson",
          "store_config": {
            "file_path": "/opt/confidential-containers/rvps/reference-values/reference-values.json"
          }
         }
      },
      "policy_engine_config": {
        "policy_path": "/opt/confidential-containers/opa/policy.rego"
      }
    }

  2. Maak de configuratietoewijzing door de volgende opdracht uit te voeren:

    $ oc apply -f kbs-config-cm.yaml

Beheerder configureren

Configureer de volgende instellingen voor beheerders:

Referentiewaarden configureren

U kunt referentiewaarden voor de RvPS (Reference Value Provider Service) configureren door de vertrouwde samenvattingen van uw hardwareplatform op te geven.

De client verzamelt metingen van de actieve software, de TEE-hardware (Trusted Execution Environment) en firmware en verzendt een offerte met de claims naar de Attestation-server. Deze metingen moeten overeenkomen met de vertrouwde samenvattingen die zijn geregistreerd bij de trustbeheerder. Dit proces zorgt ervoor dat de vertrouwelijke VM (CVM) de verwachte softwarestack uitvoert en niet is gemanipuleerd.

  1. Maak een rvps-configmap.yaml manifestbestand:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: rvps-reference-values
  namespace: trustee-operator-system
data:
  reference-values.json: |
    [ 
    ]

    Geef reference-values.json indien nodig de vertrouwde samenvattingen voor uw hardwareplatform op. Anders laat u het leeg.

  2. Maak de RVPS-configuratietoewijzing door de volgende opdracht uit te voeren:

    $ oc apply -f rvps-configmap.yaml

Uw eigen attestation-beleid maken

U kunt het standaardverklaringsbeleid overschrijven door uw eigen attestation-beleid te maken.

  1. Maak een attestation-policy.yaml-manifestbestand volgens het volgende voorbeeld:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: attestation-policy
  namespace: trustee-operator-system
data:
  default.rego: |
     package policy
     import future.keywords.every

     default allow = false

     allow {
        every k, v in input {
            judge_field(k, v)
        }
     }

     judge_field(input_key, input_value) {
        has_key(data.reference, input_key)
        reference_value := data.reference[input_key]
        match_value(reference_value, input_value)
     }

     judge_field(input_key, input_value) {
        not has_key(data.reference, input_key)
     }

     match_value(reference_value, input_value) {
        not is_array(reference_value)
        input_value == reference_value
     }

     match_value(reference_value, input_value) {
        is_array(reference_value)
        array_include(reference_value, input_value)
     }

     array_include(reference_value_array, input_value) {
        reference_value_array == []
     }

     array_include(reference_value_array, input_value) {
        reference_value_array != []
        some i
        reference_value_array[i] == input_value
     }

     has_key(m, k) {
        _ = m[k]
     }

    Voor het package policyattestation-beleid volgt u de specificatie van de Open Policy Agent. In dit voorbeeld vergelijkt het attestation-beleid de claims in het attestation-rapport met de referentiewaarden die zijn geregistreerd in de RVPS-database. Het attestation-proces is alleen geslaagd als alle waarden overeenkomen.

  2. Maak de configuratietoewijzing voor attestation-beleid door de volgende opdracht uit te voeren:

    $ oc apply -f attestation-policy.yaml

Cacheservice voor certificaat inrichten voor TDX

Als uw TEE Intel Trust Domain Extensions (TDX) is, moet u de Provisioning Certificate Caching Service (PCCS) configureren. PcCS haalt PCK-certificaten (Provisioning Certification Key) op en slaat deze in een lokale database in de cache op.

  1. Maak een tdx-config.yaml-manifestbestand:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: tdx-config
  namespace: trustee-operator-system
data:
  sgx_default_qcnl.conf: | \
      {
        "collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/",
        "pccs_url": "<pccs_url>"
      }

    Geef pccs_urlbijvoorbeeld de PCCS-URL op https://localhost:8081/sgx/certification/v4/.

  2. Maak de TDX-configuratietoewijzing door de volgende opdracht uit te voeren:

    $ oc apply -f tdx-config.yaml

Een geheim maken voor verificatie van containerinstallatiekopiehandtekening

Als u verificatie van de handtekening voor containerinstallatiekopieën gebruikt, moet u een geheim maken dat de ondertekeningssleutel voor de openbare containerinstallatiekopie bevat. De beheerder gebruikt het geheim om de handtekening te controleren, zodat alleen vertrouwde en geverifieerde containerinstallatiekopieën in uw omgeving worden geïmplementeerd.

  1. Maak een geheim voor verificatie van de handtekening voor containerinstallatiekopieën door de volgende opdracht uit te voeren:

    $ oc apply secret generic <type> \
    --from-file=<tag>=./<public_key_file> \
    -n trustee-operator-system
    • Geef bijvoorbeeld het type KBS-geheim img-sigop.
    • Geef de geheime tag op, bijvoorbeeld pub-key, en de ondertekeningssleutel voor de openbare containerinstallatiekopieën.

  2. Noteer de <type> waarde. U moet deze waarde toevoegen aan de sleutel spec.kbsSecretResources wanneer u de aangepaste KbsConfig-resource maakt.

Het verificatiebeleid voor containerinstallatiekopieën voor handtekeningen maken

U moet het verificatiebeleid voor de handtekening van de containerinstallatiekopie maken omdat handtekeningverificatie altijd is ingeschakeld.

Belangrijk

Als dit beleid ontbreekt, worden de pods niet gestart. Als u geen verificatie van de handtekening voor containerinstallatiekopieën gebruikt, maakt u het beleid zonder handtekeningverificatie.

  1. Maak een security-policy-config.json-bestand volgens de volgende voorbeelden:

    Zonder handtekeningverificatie:

    {
        "default": [
        {
        "type": "insecureAcceptAnything"
        }],
        "transports": {}
    }

    Met handtekeningverificatie:

    {
        "default": [
        {
        "type": "insecureAcceptAnything"
        ],
        "transports": {
        "<transport>": {
        "<registry>/<image>":
        [
        {
        "type": "sigstoreSigned",
        "keyPath": "kbs:///default/<type>/<tag>"
        }
        ]
        }
        }
    }
    • Geef de opslagplaats voor installatiekopieën op voor transport, bijvoorbeeld Docker.
    • Geef het containerregister en de installatiekopieën op, bijvoorbeeld 'quay.io/my-image'.
    • Geef het type en de tag op van het verificatiegeheim voor de handtekening van de containerinstallatiekopie dat u hebt gemaakt, bijvoorbeeld 'img-sig/pub-key'.

  2. Maak het beveiligingsbeleid door de volgende opdracht uit te voeren:

    $ oc apply secret generic security-policy \
    --from-file=osc=./<security-policy-config.json> \
    -n trustee-operator-system

    Wijzig het geheime type, het beveiligingsbeleid of de sleutel, osc niet.

    Het beveiligingsbeleidsgeheim wordt opgegeven in de spec.kbsSecretResources sleutel van de aangepaste KbsConfig-resource.

De aangepaste KbsConfig-resource maken

U moet de aangepaste KbsConfig-resource maken om de beheerder te starten.

  1. Maak een kbsconfig-cr.yaml manifestbestand:

    apiVersion: confidentialcontainers.org/v1alpha1
kind: KbsConfig
metadata:
  labels:
    app.kubernetes.io/name: kbsconfig
    app.kubernetes.io/instance: kbsconfig
    app.kubernetes.io/part-of: trustee-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: trustee-operator
  name: kbsconfig
  namespace: trustee-operator-system
spec:
  kbsConfigMapName: kbs-config-cm
  kbsAuthSecretName: kbs-auth-public-key
  kbsDeploymentType: AllInOneDeployment
  kbsRvpsRefValuesConfigMapName: rvps-reference-values
  kbsSecretResources: ["kbsres1", "security-policy", "<type>"]
  kbsResourcePolicyConfigMapName: resource-policy
    # tdxConfigSpec:
    #   kbsTdxConfigMapName: tdx-config
    #   kbsAttestationPolicyConfigMapName: attestation-policy
    #   kbsServiceType: <service_type>
    • Optioneel: Geef de type waarde op van het verificatiegeheim voor de handtekening van de containerinstallatiekopie als u bijvoorbeeld img-sighet geheim hebt gemaakt. Als u het geheim niet hebt gemaakt, stelt u de kbsSecretResources waarde in op ["kbsres1", "security-policy"].
    • Verwijder opmerkingen tdxConfigSpec.kbsTdxConfigMapName: tdx-config voor Intel Trust Domain Extensions.
    • Verwijder opmerkingen kbsAttestationPolicyConfigMapName: attestation-policy als u een aangepast attestation-beleid maakt.
    • Verwijder opmerkingen kbsServiceType: <service_type> als u een ander servicetype dan de standaardClusterIP-service maakt om toepassingen beschikbaar te maken binnen het externe clusterverkeer. U kunt opgeven NodePort, LoadBalancerof ExternalName.

  2. Maak de aangepaste KbsConfig-resource door de volgende opdracht uit te voeren:

    $ oc apply -f kbsconfig-cr.yaml

De configuratie van de beheerder controleren

Controleer de configuratie van de beheerder door de pods en logboeken van de beheerder te controleren.

  1. Stel het standaardproject in door de volgende opdracht uit te voeren:

    $ oc project trustee-operator-system

  2. Controleer de pods door de volgende opdracht uit te voeren:

    $ oc get pods -n trustee-operator-system

    Voorbeelduitvoer

    NAME                                                   READY   STATUS    RESTARTS   AGE
trustee-deployment-8585f98449-9bbgl                    1/1     Running   0          22m
trustee-operator-controller-manager-5fbd44cd97-55dlh   2/2     Running   0          59m

  3. Stel de omgevingsvariabele POD_NAME in door de volgende opdracht uit te voeren:

    $ POD_NAME=$(oc get pods -l app=kbs -o jsonpath='{.items[0].metadata.name}' -n trustee-operator-system)

  4. Controleer de podlogboeken door de volgende opdracht uit te voeren:

    $ oc logs -n trustee-operator-system $POD_NAME

    Voorbeelduitvoer

    [2024-05-30T13:44:24Z INFO  kbs] Using config file /etc/kbs-config/kbs-config.json
    [2024-05-30T13:44:24Z WARN  attestation_service::rvps] No RVPS address provided and will launch a built-in rvps
    [2024-05-30T13:44:24Z INFO  attestation_service::token::simple] No Token Signer key in config file, create an ephemeral key and without CA pubkey cert
    [2024-05-30T13:44:24Z INFO  api_server] Starting HTTPS server at [0.0.0.0:8080]
    [2024-05-30T13:44:24Z INFO  actix_server::builder] starting 12 workers
    [2024-05-30T13:44:24Z INFO  actix_server::server] Tokio runtime found; starting in existing Tokio runtime

Het attestation-proces controleren

U kunt het attestation-proces controleren door een testpod te maken en het geheim op te halen.

Belangrijk: Deze procedure is een voorbeeld om te controleren of attestation werkt. Schrijf geen gevoelige gegevens naar standaard-I/O omdat de gegevens kunnen worden vastgelegd met behulp van een geheugendump. Alleen gegevens die naar het geheugen worden geschreven, worden versleuteld.

Standaard schakelt een beleid aan de agentzijde dat is ingesloten in de installatiekopieën van de pod-VM de exec- en logboek-API's voor een Pod Confidential Containers uit. Dit beleid zorgt ervoor dat gevoelige gegevens niet naar standaard-I/O worden geschreven.

In een testscenario kunt u de beperking tijdens runtime overschrijven door een beleidsaantekening toe te voegen aan de pod. Voor Technology Preview worden beleidsaantekeningen voor runtime niet geverifieerd door externe attestation.

  1. Maak een verification-pod.yaml-manifestbestand:

    apiVersion: v1
kind: Pod
metadata:
  name: ocp-cc-pod
  labels:
    app: ocp-cc-pod
  annotations:
    io.katacontainers.config.agent.policy: cGFja2FnZSBhZ2VudF9wb2xpY3kKCmRlZmF1bHQgQWRkQVJQTmVpZ2hib3JzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgQWRkU3dhcFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENsb3NlU3RkaW5SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBDb3B5RmlsZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZVNhbmRib3hSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBEZXN0cm95U2FuZGJveFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEV4ZWNQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR2V0TWV0cmljc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEdldE9PTUV2ZW50UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR3Vlc3REZXRhaWxzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTGlzdEludGVyZmFjZXNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBMaXN0Um91dGVzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTWVtSG90cGx1Z0J5UHJvYmVSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBPbmxpbmVDUFVNZW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBQYXVzZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFB1bGxJbWFnZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFJlYWRTdHJlYW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVTdGFsZVZpcnRpb2ZzU2hhcmVNb3VudHNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXNlZWRSYW5kb21EZXZSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXN1bWVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTZXRHdWVzdERhdGVUaW1lUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2V0UG9saWN5UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2lnbmFsUHJvY2Vzc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFN0YXJ0Q29udGFpbmVyUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhcnRUcmFjaW5nUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhdHNDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTdG9wVHJhY2luZ1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFR0eVdpblJlc2l6ZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUVwaGVtZXJhbE1vdW50c1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUludGVyZmFjZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZVJvdXRlc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFdhaXRQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgV3JpdGVTdHJlYW1SZXF1ZXN0IDo9IHRydWUK
spec:
  runtimeClassName: kata-remote
  containers:
    - name: skr-openshift
      image: registry.access.redhat.com/ubi9/ubi:9.3
      command:
        - sleep
        - "36000"
      securityContext:
        privileged: false
        seccompProfile:
          type: RuntimeDefault

    De podmetada annotations overschrijft het beleid dat voorkomt dat gevoelige gegevens naar standaard-I/O worden geschreven.

  2. Maak de pod door de volgende opdracht uit te voeren:

    $ oc create -f verification-pod.yaml

  3. Maak verbinding met de Bash-shell van de ocp-cc-pod pod door de volgende opdracht uit te voeren:

    $ oc exec -it ocp-cc-pod -- bash

  4. Haal het podgeheim op door de volgende opdracht uit te voeren:

    $ curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1

    Voorbeelduitvoer
    res1val1

    De beheerderserver retourneert het geheim alleen als de attestation is geslaagd.