Empfehlungen und optimale Vorgehensweisen
Dieses Thema enthält Empfehlungen und optimale Vorgehensweisen für die Verwendung von Codebeamer AI in einer kundenseitig gehosteten Bereitstellung.
Terraform-Repository
Speichern Sie IaC-Terraform-Konfigurationen in einem internen, versionskontrollierten Repository.
• Kontrolle und Verfolgbarkeit: Alle IaC-Änderungen sind versioniert, überprüfbar und auditierbar und einfacher rückgängig zu machen.
• Konsistenz und Wiederherstellung: Umgebungen können zuverlässig neu erstellt werden, wodurch Konfigurationsabweichungen reduziert werden.
• Sichere Automatisierung: Continuous Integration- und Deployment-Pipelines können IaC mithilfe von Richtlinienprüfungen validieren und bereitstellen.
Container-Registry und Helm-Repository
• Importieren Sie das Docker-Image des KI-Diensts in eine interne Container-Registry des Unternehmens, z.B. Azure Container Registry (ACR) oder eine andere OCI-kompatible Registrierung.
• Speichern und versionieren Sie Helm-Charts im internen Helm- oder OCI-Repository. Richten Sie Chart-Versionen und Image-Tags an der freigegebenen Version aus, um konsistente und wiederholbare Bereitstellungen zu gewährleisten.
Bereitstellungsidentität und Zugriff
Identitäten nach Bereitstellungskomponente trennen
Verwenden Sie separate Identitäten für die Infrastrukturbereitstellung, Richtlinienverwaltung und Dienstbereitstellung.
◦ Infrastruktur: Verwenden Sie einen dedizierten Infrastruktur-Dienstprinzipal und beschränken Sie dessen Gültigkeitsbereich ausschließlich auf das von Terraform verwendete Abonnement.
◦ Azure-Richtlinie: Erstellen Sie einen separaten Richtlinien-Dienstprinzipal.
◦ Dienstbereitstellung (Helm/Docker): Verwenden Sie eine Azure AD- bzw. Entra ID-Gruppe.
▪ Fügen Sie dieser Gruppe alle Benutzer hinzu, die Zugriff auf AKS benötigen.
▪ Gruppen-ID als Eingabe an Terraform übergeben.
 |
Es wird empfohlen, Dienstprinzipale für automatisierte Workflows und Azure AD-Benutzer/-Gruppen für interaktive Operationen zu bevorzugen.
|
Isolierung von Umgebung und Terraform-Status
Für sichere und gut wartbare Umgebungen sollten – wo sinnvoll – separate Containereinheiten verwendet werden.
• Verwenden Sie separate Ressourcengruppen pro Umgebung, um Terraform-Statusdateien zu speichern, z.B.:
◦ Entwicklung: ptc-cbai-dev-store-rg
◦ Staging-Umgebung: ptc-cbai-test-store-rg
◦ Produktionsumgebung: ptc-cbai-prod-store-rg
• Speicherkonten in der Ressourcengruppe
Verwenden Sie separate Speicherkonten für den Terraform-Status oder Netzwerkflussprotokolle in allen Umgebungen.
◦ Ein Speicherkonto für Terraform-Status
Beispiel: devtfstate, tsttfstate, prodtfstate
◦ Ein Speicherkonto für virtuelle Netzwerkflussprotokolle
Beispiel: devflowlogs, tstflowlogs, prodflowlogs
• Blob-Container im Terraform-Statuskonto
◦ Speichern Sie den Infrastruktur‑ und Richtlinienstatus in separaten Containern.
Beispiel:
▪ infra-tfstate - Infrastruktur-Terraform-Status
▪ policy-tfstate - Azure-Richtlinien-Terraform-Status
• Stellen Sie sicher, dass RBAC und Benennungskonventionen in Entwicklungs-, Test- und Produktionsumgebungen konsistent sind.
AKS-Hostverschlüsselung
• aks_host_encryption_enabled aktiviert die Verschlüsselung auf Hostebene für AKS-Knoten-VMs.
• Bei Aktivierung verschlüsselt Azure temporäre Datenträger, den Cache des Betriebssystemdatenträgers sowie den Datenfluss zwischen VM und Host.
• Dies erhöht die Sicherheit und unterstützt die Einhaltung von Compliance‑Anforderungen für regulierte Workloads.
• Bei Deaktivierung bleiben verwaltete Datenträger weiterhin standardmäßig im Ruhezustand verschlüsselt; betroffen ist ausschließlich die Host‑Level‑Verschlüsselung.