Häufig gestellte Fragen zu Confidential Computing-Knoten in Azure Kubernetes Service (AKS)

Ja, für Intel SGX Enclave-Knoten.

Ja, DCSv3-VM-Knoten unterstützen den beschleunigten Netzwerkbetrieb. Virtuelle DCSv2-Computer nicht.

Zurzeit sind Azure Confidential Computing DCSv2/DCSv3-VMs bei Intel SGX DCAP 1.33.2 installiert.

Nein Auf der AKS-Engine basierende Confidential Computing-Knoten unterstützen Confidential Computing-Knoten, die benutzerdefinierte Installationen zulassen und die vollständige Kontrolle über Ihre Kubernetes-Steuerungsebene haben.

Ja. Sie können unterschiedliche Knotenpools innerhalb desselben AKS-Clusters ausführen, einschließlich ACC-Knoten. Wenn Sie Ihre Enklavenanwendungen in einem bestimmten Knotenpool als Ziel verwenden möchten, ziehen Sie das Hinzufügen von Knotenselektoren oder Anwenden von EPC-Limits in Betracht. Weitere Informationen finden Sie im Schnellstart für vertrauliche Knoten hier.

Derzeit leider nicht. Wenden Sie sich unter acconaks@microsoft.com an das Produktteam, wenn Sie Unterstützung für Windows-Knoten oder -Container benötigen.

Ja. Die VMs haben auch einen regulären Arbeitsspeicher, der Standardcontainer-Workloads ausführen kann. Berücksichtigen Sie das Sicherheits- und Bedrohungsmodell Ihrer Anwendungen, bevor Sie über die Bereitstellungsmodelle entscheiden.

DCSv2/DCsv3-SKUs. Mehr über DCSv2 und DCSv3 finden Sie in den unterstützten Regionen

Ja. Die Azure CLI könnte auch als Alternative verwendet werden, wie hier beschrieben wird.

18.04 für Gen 2.

• Unterstützt nur VM-Knoten für Ubuntu 18.04 Gen 2
• Keine Unterstützung für Windows-Knoten oder Windows-Container
• EPC-speicherbasierte horizontale automatische Podskalierung wird nicht unterstützt. CPU und reguläre speicherbasierte Skalierung wird unterstützt.
• Dev Spaces in AKS für vertrauliche Apps wird zurzeit nicht unterstützt.

Ja. Die Azure CLI könnte auch als Alternative verwendet werden, wie hier beschrieben wird.

Ja, Sie bringen SGX-Wrapper-Software zur Ausführung in einer Intel SGX-Enklave mit. Weitere Einzelheiten zu den Plattform-Enablern finden Sie auf der Seite vertrauliche Container.

Verschiedene Grundvoraussetzungen (ISVs und OSS-Projekte) bieten Möglichkeiten zum Aktivieren von vertraulichen Containern. Weitere Details und individuelle Verweise auf Implementierungen finden Sie auf der Seite „Vertrauliche Container“.

Nachweis ist der Prozess zur Veranschaulichung und Überprüfung, dass ein Softwareelement auf der jeweiligen Hardwareplattform ordnungsgemäß instanziiert wurde. Außerdem stellt er sicher, dass sein Beweis überprüft werden kann, um zu gewährleisten, dass er auf einer sicheren Plattform ausgeführt wird und nicht manipuliert wurde. Informieren Sie sich genauer dazu, wie ein Nachweis bei Enklaven-Apps geführt wird.

Der EPC-Speicher bezieht sich auf den Teil Ihrer Anwendung, der zur Ausführung in der Enklave programmiert wurde. Die Gesamtgröße Ihres Containers ist nicht die richtige Methode für einen Vergleich mit dem maximal verfügbaren EPC-Speicher. Tatsächlich ermöglichen DCSv2-Computer mit SGX einen maximalen VM-Arbeitsspeicher von 32 GB, in dem Ihr nicht vertrauenswürdiger Teil der Anwendung genutzt würde. Wenn Ihr Container aber mehr als den verfügbaren EPC-Speicher verbraucht, könnte die Leistung des Programmteils, der in der Enklave ausgeführt wird, dadurch beeinträchtigt werden.

Zur besseren Verwaltung des EPC-Speichers in den Workerknoten sollten Sie die EPC-speicherbasierte Verwaltung von Grenzwerten über Kubernetes in Erwägung ziehen. Nutzen Sie das folgende Beispiel als Referenz.

apiVersion: batch/v1
kind: Job
metadata:
  name: sgx-test
  labels:
    app: sgx-test
spec:
  template:
    metadata:
      labels:
        app: sgx-test
    spec:
      containers:
      - name: sgxtest
        image: oeciteam/sgx-test: 1.0
        resources:
          limits:
            sgx.intel.com/sgx_epc_mem_in_MiB: 10 # This limit will automatically place the job into confidential computing node. Alternatively, you can target deployment to node pools
      restartPolicy: Never
  backoffLimit: 0

Der gesamte verfügbare EPC-Speicher wird von den Enklavenanwendungen auf denselben VMs oder Workerknoten gemeinsam genutzt. Wenn Ihre Anwendung mehr als den verfügbaren EPC-Speicher nutzt, wirkt sich dies möglicherweise auf ihre Leistung aus. Deshalb empfehlen wir, die Toleranz pro Anwendung in Ihrer YAML-Datei für die Bereitstellung festzulegen, um den verfügbaren EPC-Speicher pro Workerknoten besser verwalten zu können, wie in den vorstehenden Beispielen gezeigt wird. Alternativ können Sie jederzeit wahlweise auf den VM-Größen des Workerknotenpools nach oben navigieren oder weitere Knoten hinzufügen.

Azure Confidential Computing DCsv2 SKU-VMs unterstützen zurzeit einen einzigen Adressraum für das Programm, das in einer Enklave ausgeführt wird. Ein einzelner Prozess ist eine aktuelle Einschränkung, die mit dem Fokus auf hohe Sicherheit konzipiert wurde. Bei den Grundvoraussetzungen für vertrauliche Container gibt es jedoch möglicherweise alternative Implementierungen, um diese Einschränkung zu umgehen.

Nein Produkt bietet ACC Add On, dass die (confcom) wird Ihnen helfen, mit diesem. Weitere Informationen zu den Bereitstellungsdetails finden Sie hier.

Nein Wir empfehlen Ihnen zur Ausführung von benutzerdefinierten Installationen, Bereitstellungen von AKS-Engine Confidential Computing-Workerknoten zu wählen.

Nicht nativ während der Enklaveninitialisierung, die Signatur kann jedoch per Nachweis überprüft werden. Weitere Informationen finden Sie hier.

Bei vertraulichen Containern können Sie den Enklavencode signieren, nicht aber den Docker-Container selbst. Bei Enclave-Code (typischerweise Ihr Kernanwendungscode in Java, Python usw.) können Sie die MRSIGNER-Details des Enclave-Codes durch Attestierung verifizieren, bevor Sie dem Code und der Ausführungsumgebung durch den Attestierungsfluss vertrauen können.

Nächste Schritte

Weitere Informationen zu vertraulichen Containern finden Sie auf der Seite „Vertrauliche Container“.