Übersicht über die Verschlüsselung
Virtual Private Cloud Klassische Infrastruktur Satellite
Schützen Sie sensible Informationen in Ihrem Red Hat® OpenShift® on IBM Cloud® Cluster, um die Datenintegrität zu gewährleisten und zu verhindern, dass Ihre Daten unbefugten Nutzern zugänglich gemacht werden, indem Sie einen Key Management Service (KMS) Provider einrichten.
Red Hat OpenShift on IBM Cloud bietet Verschlüsselung auf mehreren Ebenen in Ihrem Cluster. Die Verschlüsselung für einige Komponenten wird von IBM verwaltet, während Sie für andere Komponenten die Möglichkeit haben, Ihre eigenen KMS-Anbieter-Anmeldedaten mitzubringen, um die Verschlüsselung selbst zu verwalten.
In der folgenden Tabelle sind die Verschlüsselungsoptionen für Red Hat OpenShift on IBM Cloud Cluster.
| Komponente | Standardmäßig verschlüsselt? | Bringen Sie Ihren eigenen Schlüsselträger mit? | Aktivierungszeit | Unterstützte KMS-Provider | Kontenübergreifende Unterstützung? |
|---|---|---|---|---|---|
| Steuerebene | Ja | Nein | Während der Clustererstellung. | IBM gelang es Key Protect | Nicht zutreffend |
| Platten für Workerknoten | Ja | Ja | Während der Clustererstellung oder Worker-Pool-Erstellung. | Key Protect | Ja |
| Geheime Clusterschlüssel | Nein | Ja | Nach der Clustererstellung mithilfe von kms enable. |
Key Protect | Kontoübergreifende Unterstützung nur für Classic-und VPC-Cluster. |
| Persistenter Speicher | Das hängt vom Speicheranbieter ab. | Abhängig vom Provider | Nach der Clustererstellung beim Einrichten des Speichers. | Key Protect | Das hängt vom Speicheranbieter ab. |
Steuerebene
Die Verschlüsselung der Kontrollebene wird verwaltet von IBM.
- Die Komponenten im Red Hat OpenShift Master booten auf einem LUKS-verschlüsselten Laufwerk mit einem IBM-verwalteten Schlüssel.
- Die etcd-Komponente des Masters speichert die Konfigurationsdateien Ihrer Kubernetes-Ressourcen, wie z. B. Bereitstellungen und geheime Schlüssel.
- Daten in etcd werden auf dem lokalen Datenträger des Kubernetes-Masters gespeichert und in IBM Cloud Object Storage gesichert.
- Daten werden während des Transits an IBM Cloud Object Storage verschlüsselt und wenn sie ruhen.
Workerknotenplatten
Angeschlossene Festplatten werden zum Booten Ihres Worker Nodes, zum Hosten des Container-Dateisystems und zum Speichern lokal gezogener Images verwendet. Die Verschlüsselung und die Anzahl der Platten variieren je nach Infrastrukturprovider.
Es gibt eine vorübergehende Einschränkung bei der Verwendung einer Key Protect Single-Tenant-Instanz für die BYOK-Verschlüsselung (Bring Your Own Key) für die Boot-Diskette der Arbeitsknoten und die geheime Verschlüsselung des Clusters. Um eine Single-Tenant-Instanz mit Ihrem Cluster zu verwenden, müssen Sie sicherstellen, dass ihre Service-to-Service-Autorisierungsrichtlinie auf die Key Protect Service- oder Instanzebene und nicht auf einen Schlüssel oder Schlüsselring beschränkt ist. Diese Einschränkung gilt nur für Key Protect single tenant instances.
- VPC-Workerknoten
- Standardmäßig wird die eine primäre Festplatte der VPC-Arbeitsknoten vom zugrundeliegenden VPC-Infrastrukturanbieter im Ruhezustand mit AES-256 verschlüsselt. Sie können die Verschlüsselung der Workerknoten verwalten, indem Sie einen KMS-Provider auf der Workerpoolebene aktivieren. Weitere Informationen zur Verschlüsselung von VPC-Workerknotenplatten finden Sie unter Plattenverschlüsselung für Workerknoten für VPC-Cluster konfigurieren.
- Klassische Workerknoten
- Die primäre Platte enthält die Kernel-Images zum Booten Ihres Workerknotens. Diese Festplatte ist nicht verschlüsselt. Die zweite (sekundäre) Platte enthält das Containerdateisystem und die lokal extrahierten Images. Diese Platte ist mit einer AES-256-Bit-Verschlüsselung und einem von IBM verwalteten LUKS-Verschlüsselungsschlüssel ausgestattet, der für den Workerknoten eindeutig ist und in Ihrem Cluster als geheimer Kubernetes-Schlüssel gespeichert wird. Wenn Sie Ihre Workerknoten erneut laden oder aktualisieren, werden die LUKS-Schlüssel turnusmäßig gewechselt.
- Satellite-Workerknoten
- Die Verschlüsselung der Betriebssystemplatte und der sekundären Platte wird auf der IAAS-Ebene der Plattform Satellite verwaltet. Die Verschlüsselung persistenter Speicherdatenträger, die innerhalb des Clusters verwendet werden, wird auf der Ebene des persistenten Speicher-Plug-ins und der Sicherungsspeichereinheit verwaltet. Weitere Informationen zur Verschlüsselung für Speichereinheiten oder Plug-ins finden Sie in der Dokumentation zum Einheitenprovider oder in der Dokumentation zum Speicher-Plug-in.
Geheime Clusterschlüssel
Geheime Kubernetes-Schlüssel sind standardmäßig base64 codiert. Sie können die Geheimnisse von Kubernetes und alle in den Geheimnissen gespeicherten Anmeldeinformationen weiter schützen, indem Sie einen Schlüsselverwaltungsdienst (KMS) wie IBM® Key Protect for IBM Cloud® aktivieren.
Es gibt eine vorübergehende Einschränkung bei der Verwendung einer Key Protect Single-Tenant-Instanz für die BYOK-Verschlüsselung (Bring Your Own Key) für die Boot-Diskette der Arbeitsknoten und die geheime Verschlüsselung des Clusters. Um eine Single-Tenant-Instanz mit Ihrem Cluster zu verwenden, müssen Sie sicherstellen, dass ihre Service-to-Service-Autorisierungsrichtlinie auf die Key Protect Service- oder Instanzebene und nicht auf einen Schlüssel oder Schlüsselring beschränkt ist. Diese Einschränkung gilt nur für Key Protect single tenant instances.
Wenn Sie einen KMS-Anbieter (Key Management Service) für Ihren Cluster aktivieren, bringen Sie Ihren eigenen Stammschlüssel mit. Der Rootschlüssel wird zum Verschlüsseln der Datenverschlüsselungsschlüssel (DEKs) verwendet, die dann zum Verschlüsseln der geheimen Schlüssel in Ihrem Cluster verwendet werden. Der Rootschlüssel wird in der KMS-Providerinstanz gespeichert, die Sie steuern. Die verschlüsselten DEKs werden in 'etcd' gespeichert und können nur mit dem Rootschlüssel des KMS-Providers unverschlüsselt werden. Weitere Informationen zur Funktionsweise der Schlüsselverschlüsselung finden Sie unter Umschlagverschlüsselung.
Lesen Sie die folgenden Hinweise zur Verschlüsselung geheimer Clusterschlüssel.
- Geheime Clusterschlüssel werden mit Ihrem KMS verschlüsselt.
- Geheime Clusterschlüssel werden nach der Rotation der Rootschlüssel automatisch aktualisiert.
- Cluster, die den Rootschlüssel verwenden, können über die KMS-Providerschnittstelle angezeigt werden.
- Cluster reagieren automatisch, wenn Sie Rootschlüssel inaktivieren, aktivieren oder wiederherstellen.
- Wenn Sie einen Rootschlüssel inaktivieren, wird die Clusterfunktionalität eingeschränkt, bis Sie den Schlüssel wieder aktivieren.
- Durch das Löschen eines Rootschlüssels wird der Cluster nicht mehr verwendbar und nicht wiederherstellbar.
- Sie können jeweils nur einen KMS-Anbieter und -Schlüssel im Cluster aktiviert haben.
- Sie können den KMS-Anbieter und den Schlüssel wechseln.
- Sie können die Verschlüsselung des KMS-Providers nicht inaktivieren.
Informationen zum Einrichten der geheimen Clusterverschlüsselung finden Sie unter Einrichten der geheimen Cluster-Verschlüsselung.
Persistenter Speicher
Je nach Typ des von Ihnen verwendeten persistenten Speichers können Sie die auf die Speicherdatenträger geschriebenen Daten verschlüsseln, indem Sie einen KMS-Provider aktivieren. Weitere Informationen zu den verfügbaren Typen von persistentem Speicher und Verschlüsselung finden Sie unter Informationen zu Ihren Speicheroptionen.
Nächste Schritte
Um die Planung fortzusetzen, wählen Sie eine Lagerungsoption. Wenn Sie bereit sind, mit der Verschlüsselung zu beginnen, fahren Sie fort mit Erstellen einer KMS-Instanz und eines Root-Schlüssels.