Oracle Cloud Infrastructure - Dokumentation

Kerberos-Authentifizierung verwenden

Der File Storage-Service bietet eine Kerberos-Authentifizierung, um eine starke Authentifizierungsoption bereitzustellen.

Die NFS v.3 Unix-Sicherheit, bei der dem NFS-Client die Wahrheit über die Identität eines Benutzers vertraut wird, bietet nur grundlegende Sicherheit. Die Identität des Benutzers in jedem NFS-Aufruf wird vom Aufrufer definiert, und die Identität wird nicht von einem vertrauenswürdigen Dritten überprüft.

Kerberos für NFSv3 bietet starke Authentifizierung für Hosts und Benutzer. Es kann auch den Nachweis der Integrität von Daten bieten, um sicherzustellen, dass die Daten nicht manipuliert werden, und die Privatsphäre der Daten schützen. Datenintegrität und Datenschutz sind mit NFS v.3 UNIX-Sicherheit nicht möglich, ohne spezielle Clientsoftware zu installieren oder weitere TCP-Ports zu öffnen.

  • Benutzer und Services in einem Kerberos-fähigen Netzwerk werden als Principals bezeichnet. Ein Kerberos-Principal hat das Format primary/instance@realm. Weitere Informationen finden Sie in der Dokumentation zum MIT Kerberos-Principal.
  • Das Key Distribution Center (KDC) authentifiziert Principals und stellt Tickets aus. Das KDC verwaltet eine Liste der Principals und deren Kennwörter.
  • Eine Realm besteht aus allen Principals, die von einem KDC unterstützt werden.

Der File Storage-Service unterstützt die Kerberos-Authentifizierung über RPCSEC_GSS (RFC2203) mit den folgenden Sicherheitsoptionen:

  • Verwenden Sie den Modus KRB5 zur Authentifizierung über NFS
  • Verwenden Sie den Modus KRB5I für die Authentifizierung über NFS und Datenintegrität (nicht autorisierte Änderung von Daten während der Übertragung)
  • Verwenden Sie den Modus KRB5P für die Authentifizierung über NFS, Datenintegrität und Datenschutz (Verschlüsselung während der Übertragung)

Features

Die Unterstützung von File Storage Service von Kerberos umfasst die folgenden Features.

Verschlüsselung während der Übertragung:

Sie können den Kerberos-Modus KRB5P verwenden, der Datenschutz bietet, als Alternative zur TLS v.1.2 (Transport Layer Security)-Verschlüsselung. Die TLS v.1.2-Verschlüsselung erfordert die Installation eines Packages namens oci-fss-utils oder die Verwendung von stunnel, je nach Betriebssystem. Die Anzahl der verschlüsselten NFS/TLS-Verbindungen für ein Mountziel ist begrenzt. Wenn Sie Kerberos mit der Option KRB5P verwenden, können Sie die Verschlüsselung während der Übertragung in einer Größenordnung verwenden, die mit NFS über TLS nicht möglich ist.

Kerberos und Sicherheit nach IP

Die Sicherheit nach IP, die mit NFS-Exportoptionen festgelegt wird, ist angemessen sicher, wenn sich die IP-Adressen in OCI befinden und die Hosts vertrauenswürdig sind. Kerberos für NFSv3 kann eine höhere Sicherheitsebene für gemischte Umgebungen oder Umgebungen mit nicht vertrauenswürdigen Hosts bieten.

Sie können einen CIDR-Block so konfigurieren, dass Kerberos und ein anderer für die NFS-Authentifizierung AUTH_SYS bei demselben Export erforderlich sind. Clients, die aus dem vertrauenswürdigen Netzwerk gemountet werden, müssen nicht mit Kerberos gemountet werden. Clients, die aus dem nicht vertrauenswürdigen Netzwerk gemountet werden, müssen jedoch Kerberos verwenden.

LDAP-Lookups und anonymer Zugriff

Wenn Benutzer eine Identität im KDC haben, aber keine zusätzlichen Informationen im LDAP-Server vorhanden sind oder LDAP nicht aktiviert ist, kann der NFS-Vorgang fehlschlagen oder fortgesetzt werden. Das Verhalten hängt in diesen Fällen davon ab, ob Sie LDAP für das Mountziel und anonymen Zugriff für den Export aktivieren.

Anonymer Zugriff ist standardmäßig deaktiviert. Eine NFS-Anforderung, die mit einem nicht gefundenen Benutzer verknüpft ist, ist nicht erfolgreich.

Wenn der anonyme Zugriff aktiviert ist, werden Anforderungen, die mit einem Benutzer verknüpft sind, der nicht im LDAP-Server gefunden wird, mit der in den Exportoptionen festgelegten Squash-UID und Squash-GID fortgesetzt. Möglicherweise möchten Sie anonymen Zugriff zulassen, wenn der Mount-Prozess einen System-Kerberos-Principal verwendet, der nicht in Ihrem LDAP-Server vorhanden ist. Durch Squashed-Rechte können die wenigen schreibgeschützten Vorgänge, die der NFS-Client verwendet, das Dateisystem mounten.

NFS-Anforderungsszenarios für Kerberos-fähige Exporte
LDAP auf Mountziel aktiviert? LDAP-Response Anonymer Zugriff aktiviert? Squash exportieren aktiviert? NFS-Anforderung
Alle Alle Alle Ja (alle)

Wechselt mit den Einstellungen Squash-UID und Squash-GID in den Exportoptionen fort. Keine sekundäre Gruppenliste.
Jeder Jeder Jeder Ja (Wurzel)

Wechselt mit den Einstellungen Squash-UID und Squash-GID in den Exportoptionen erst nach einer erfolgreichen LDAP-Antwort, bei der der Benutzername UID 0 zugeordnet ist. Keine sekundäre Gruppenliste.

Wenn die LDAP-Antwort eine UID zurückgibt, die nicht 0 ist, wird mit der zurückgegebenen UID, GID und Gruppenliste fortgefahren.
Ja USERNAME-Übereinstimmung Jeder Nein Verwendet die vom LDAP-Server abgerufene UID, GID und sekundäre Gruppenliste.
Ja Keine Übereinstimmung mit USERNAME Ja Nein Wechselt mit den Einstellungen Squash-UID und Squash-GID in den Exportoptionen fort. Keine sekundäre Gruppenliste.
Ja Keine Übereinstimmung mit USERNAME Nein Nein Fehler bei Berechtigungen.
Ja LDAP-Fehler außer keinem übereinstimmenden Benutzer Alle Nein Fehler bei Berechtigungen.
Nein Nicht anwendbar Ja Nein

Wechselt mit den Einstellungen Squash-UID und Squash-GID in den Exportoptionen fort.
Nein Nicht anwendbar Nein Nein Fehler bei Berechtigungen.
Hinweis

Für Kerberos-fähige Exporte wird immer LDAP für Gruppenliste verwenden verwendet, wenn LDAP aktivieren auf dem Mountziel aktiviert ist.

Weitere Informationen finden Sie unter NFS-Exportoptionen.

Voraussetzungen

File Storage erfordert mehrere Voraussetzungen, um Kerberos für die Authentifizierung zu verwenden.

Die Anforderungen für die Verwendung der Kerberos-Authentifizierung pro Benutzer umfassen:

  • Vom Kunden verwaltete LDAP-Infrastruktur, um Kerberos-Principals UNIX-Identitäten zuzuordnen. Weitere Informationen finden Sie unter LDAP für Autorisierungsvoraussetzungen.
  • Vom Kunden verwaltete Kerberos-Infrastruktur MIT einem KDC wie MIT oder Microsoft Active Directory.
  • Ein DNS-Server, der den Mountzielnamen und die IP-Adresse auflösen kann. Sowohl Vorwärts- als auch Rückwärts-Lookup-Funktionen sind erforderlich.
Diese Abbildung zeigt die vom Kunden verwaltete und von OCI verwaltete Infrastruktur, die für die Kerberos-Authentifizierung erforderlich ist.
  1. Kommunikation mit einem vom Kunden verwalteten KDC-Server über TCP/UDP-Port 88.
  2. Sichere Kommunikation mit einem Kerberos-fähigen Mountziel über NFS-Port 2048/2049/2050 (optional verschlüsselt).
  3. Kommunikation mit dem DNS-Service über TCP/UDP-Port 53.
  4. Kommunikation mit dem vom Kunden verwalteten LDAP-Service über den im ausgehenden Connector konfigurierten TCP-Port. Der Standardwert ist TCP-Port 636.
  5. Daten im Ruhezustand in File Storage verschlüsselt.

LDAP-Infrastruktur

File Storage verwendet UIDs und GIDs, um den Zugriff auf Dateien zu autorisieren. File Storage verwendet LDAP, um Kerberos-Principals UIDs und GIDS zuzuordnen. Ausführliche LDAP-Infrastrukturanforderungen finden Sie unter Voraussetzungen für die Verwendung von LDAP zur Autorisierung.

Wenn File Storage Autorisierungsinformationen nicht aus LDAP suchen kann, verläuft der NFS-Zugriff auf den Kerberos-Principal wahrscheinlich nicht erfolgreich. Die Kerberos-Authentifizierung kann ohne LDAP verwendet werden. Alle authentifizierten Kerberos-Principals würden jedoch als anonym behandelt. Weitere Informationen finden Sie unter LDAP-Lookups und anonymer Zugriff.

Kerberos Keytab

Die in OCI Vault gespeicherte Kerberos-Schlüsseltabelle muss ein Base64-codiertes Zeichenfolgenarray der folgenden Struktur sein: 

<principal, key version number, cipher type, symmetric key>

Jeder Eintrag in der Schlüsseltabelle kann nur einen Principal enthalten. Dieser Principal muss den vollqualifizierten Domainnamen (FQDN) des Mountziels als Instanz enthalten. Ein Principal kann mehrere Einträge mit verschiedenen Verschlüsselungstypen oder Ciphern haben.

Beispiel: Wenn nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM der Principal in der Schlüsseltabelle ist, ist FSS_EXAMPLE.COM die Realm, fss_test.com die Instanz und nfs die Primärinstanz. Der FQDN des Mountziels in diesem Beispiel muss krb_mt1.fss_test.com lauten. Wenn Sie einen vom Kunden verwalteten DNS-Server verwenden, verwenden Sie diesen FQDN in Mountbefehlen.

Hinweis

Bei Verwendung des Standard-Internet- und VCN-Resolvers erstellt der File Storage-Service einen FQDN, indem der Hostname des Mountziels mit dem FQDN des Subnetzes kombiniert wird, in dem sich das Mountziel befindet. Nach der Erstellung kann der Hostname auf der Seite mit den Details zum Mountziel geändert werden. Weitere Informationen finden Sie unter Mountziele verwalten.

File Storage unterstützt die folgenden Cipher:

  • aes128-cts-hmac-sha256-128
  • aes256-cts-hmac-sha384-192
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
Hinweis

OCI File Storage unterstützt eine maximale Kerberos-Keytab-Größe von 1024 Byte.
Wichtig

Validieren Sie die Kerberos-Schlüsseltabelle, bevor Sie Kerberos aktivieren, um einen Verfügbarkeitsausfall zu vermeiden, der durch eine ungültige Schlüsseltabelle verursacht wird. Sie können die Schlüsseltabelle validieren, wenn Sie die Kerberos-Konfiguration eines Mountziels konfigurieren oder prüfen.

Wenn Sie die Kerberos-Schlüsseltabelle über die Konsole, die CLI oder die API validieren, prüft der File Storage-Service Folgendes:

  • Wenn die Schlüsseltabellengröße größer als 1024 Byte ist
  • Die Keytab-Versionsnummer ist nicht 1281 oder 1282
  • Wenn die Schlüsseltabelle Null-Einträge enthält
  • Wenn die Schlüsseltabelle Einträge mit unterschiedlichen Hauptnamen enthält
  • Wenn die Schlüsseltabelle mehr als 12 Einträge enthält, ist dies das Maximum
  • Wenn der Schlüsseltabellencodierungstyp nicht einer der folgenden ist:
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Hinweis

Eine aus dem KDC im Binärformat extrahierte Schlüsseltabelle muss in Base64 konvertiert und dann zum Erstellen eines Secrets in OCI Vault verwendet werden. Stellen Sie sicher, dass Sie Base64 als Format des Secrets auswählen, wenn Sie es in die konvertierte Schlüsseltabelle einfügen.

File Storage unterstützt die Rotation von Schlüsseltabellen mit einer Backup-Schlüsseltabelle. Weitere Informationen finden Sie unter Schlüssel rotieren.

Überlegungen und Einschränkungen

Berücksichtigen Sie bei der Verwendung von Kerberos für die File Storage-Authentifizierung die folgenden Informationen und Limits.

  • Für die Kerberos-Authentifizierung pro Benutzer erfordert File Storage eine vom Kunden verwaltete LDAP-(Lightweight Directory Access Protocol-)Infrastruktur, einschließlich eines LDAP-Servers, der ein RFC2307-POSIX-Schema unterstützt.
  • File Storage unterstützt eine maximale Kerberos-Keytab-Größe von 1024 Byte.

  • File Storage unterstützt die folgenden Cipher:

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • Das Mounten von Dateisystemen mit den Optionen rsize oder wsize wird nicht empfohlen. Wenn Sie Werte für diese Optionen angeben, können sie von File Storage bei Verwendung von KRB5I oder KRB5P auf 256 KB reduziert werden.
  • Die File Storage-Performance bei Verwendung des Kerberos-Authentifizierungsmodus KRB5 entspricht in etwa der Verwendung der AUTH_SYS-Authentifizierung. Die Performance wird bei Verwendung von KRB5P erheblich verringert und bei Verwendung von KRB5I leicht verringert. Die Leistung kann je nach Clientkonfiguration und Dateisystem variieren.

Überwachung und Alarme

Ein Problem schnell zu erkennen ist wichtig, wenn die Kerberos-Authentifizierung mit LDAP-Autorisierung verwendet wird. Wenn die Kerberos- oder LDAP-Infrastruktur nicht ordnungsgemäß funktioniert, können NFS-Clients den Zugriff auf File Storage-Dateisysteme verlieren, die über ihre Exporte verfügbar gemacht werden. Um solche Probleme zu erkennen, wird empfohlen, Alarme für Metriken des Mountziels festzulegen. Alarme können Sie innerhalb weniger Minuten auf Infrastrukturprobleme aufmerksam machen.

Alarme, die auf Kerberos-Fehlern, LDAP-Verbindungsfehlern und LDAP-Anforderungsfehlern basieren, erkennen Konnektivitätsprobleme zwischen Mountzielen, ausgehenden Connectors und der vom Kunden verwalteten LDAP-Infrastruktur.

Mit der folgenden Beispielabfrage können Sie einen Alarm für Kerberos-Fehler erstellen:

KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1

Mit der folgenden Beispielabfrage können Sie einen Alarm für die LDAP-Konnektivität erstellen:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Weitere Informationen zu Monitoringmetriken und zur Verwendung von Alarmen finden Sie in Überblick über Monitoring. Informationen zu Benachrichtigungen für Alarme finden Sie unter Überblick über Benachrichtigungen.

Erforderliche IAM-Policy

File Storage muss auf das LDAP-Serverkennwort zugreifen und Kerberos-Keytab Vault Secrets für das Mountziel für die Kerberos-Konfiguration bereitstellen. Sowohl der Benutzer, der das Mountziel konfiguriert, als auch das Mountziel selbst benötigen Lesezugriff.

Policy zum Verwalten von Vault Secrets

Erteilen Sie dem Benutzer oder der Gruppe, der die Vault Secret-Berechtigungen erstellt. Weitere Informationen finden Sie unter Vault-Secrets verwalten.

Policy zum Aktivieren der Mountzielkonfiguration

Erteilen Sie dem Benutzer oder der Gruppe, der Kerberos und LDAP konfiguriert, Berechtigungen für ein Mountziel mit einer Policy wie der folgenden:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <Keytab_Secret_ID>, target.secret.id = <LDAP_Password_Secret_ID> }

Auf diese Weise kann der Benutzer File Storage-Befehle absetzen, mit denen die Vault Secrets gelesen und Teile des Secrets zur Validierung angezeigt werden. File Storage zeigt dem Benutzer, der das Mountziel zur Validierung konfiguriert, den Principal, die Schlüsselversionsnummer und die Verschlüsselungstypen an.

Policy, mit der ein Mountziel Secrets abrufen kann

Der File Storage-Service erfordert die Möglichkeit, die Secrets zu lesen. File Storage verwendet Resource Principals, um einem bestimmten Set von Mountzielen Zugriff auf das Vault Secret zu erteilen. Dies ist ein zweistufiger Prozess. Zuerst müssen die Mountziele, die Zugriff benötigen, in eine dynamische Gruppe gestellt werden, und dann erhält die dynamische Gruppe Zugriff auf das Lesen der Secrets.

  1. Erstellen Sie eine dynamische Gruppe für die Mountziele mit einer Policy wie der folgenden:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Hinweis

    Wenn die dynamische Gruppe mehrere Regeln enthält, müssen Sie die Option Match any rules defined below verwenden.

  2. Erstellen Sie eine IAM-Policy, die der dynamischen Gruppe von Mountzielen Lesezugriff auf Vault Secrets erteilt:

    allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>