Documentation Oracle Cloud Infrastructure

Utilisation de l'authentification Kerberos

Le service File Storage offre une authentification Kerberos pour fournir une option d'authentification forte.

La sécurité NFS v.3 Unix, qui fait confiance au client NFS pour être fiable sur l'identité d'un utilisateur, fournit uniquement une sécurité de base. L'identité de l'utilisateur dans chaque appel NFS est définie par l'appelant et l'identité n'est pas vérifiée par un tiers de confiance.

Kerberos pour NFSv3 offre une authentification forte pour les hôtes et les utilisateurs. Il peut également fournir une preuve de l'intégrité des données, s'assurer que les données ne sont pas altérées et protéger la confidentialité des données. L'intégrité des données et la confidentialité des données ne sont pas possibles avec la sécurité UNIX NFS v.3 sans installer un logiciel client spécialisé ou ouvrir plus de ports TCP.

  • Les utilisateurs et les services d'un réseau compatible Kerberos sont appelés principaux. Un principal Kerberos a la forme primary/instance@realm. Pour plus d'informations, reportez-vous à la documentation du principal Kerberos MIT.
  • Le Centre de distribution des clés (KDC) authentifie les principaux et émet des tickets. Le KDC tient à jour une liste de principaux et de leurs mots de passe.
  • Un domaine se compose de tous les principaux pris en charge par un KDC.

Le service File Storage prend en charge l'authentification Kerberos via RPCSEC_GSS (RFC2203) avec les options de sécurité suivantes :

  • Utiliser le mode KRB5 pour l'authentification via NFS
  • Utiliser le mode KRB5I pour l'authentification via NFS et l'intégrité des données (modification non autorisée des données en transit)
  • Utiliser le mode KRB5P pour l'authentification via NFS, l'intégrité des données et la confidentialité des données (cryptage en transit)

Fonctions

La prise en charge du service File Storage de Kerberos inclut les fonctionnalités suivantes.

Cryptage en transit

Vous pouvez utiliser le mode Kerberos KRB5P, qui offre la confidentialité des données, au lieu d'utiliser le chiffrement TLS v.1.2 (Transport Layer Security). Le chiffrement TLS v.1.2 nécessite l'installation d'un package appelé oci-fss-utils ou l'utilisation de stunnel, en fonction de votre système d'exploitation. Le nombre de connexions NFS/TLS cryptées pour une cible de montage est limité, mais l'utilisation de Kerberos avec l'option KRB5P vous permet d'utiliser le cryptage en transit à une échelle qui n'est pas possible avec NFS sur TLS.

Kerberos et sécurité par IP

La sécurité par IP, définie à l'aide des options d'export NFS, est raisonnablement sécurisée si les adresses IP se trouvent dans OCI et que les hôtes sont sécurisés. Kerberos pour NFSv3 peut fournir un niveau de sécurité plus élevé pour les environnements mixtes ou les environnements avec des hôtes non sécurisés.

Vous pouvez configurer un bloc CIDR pour exiger Kerberos et un autre pour l'authentification NFS AUTH_SYS sur le même export. Les clients montant à partir du réseau de confiance n'auraient pas besoin de monter avec Kerberos, mais les clients montant à partir du réseau non de confiance auraient besoin d'utiliser Kerberos.

Recherches LDAP et accès anonyme

Lorsque les utilisateurs disposent d'une identité dans le KDC, mais qu'aucune information supplémentaire n'est disponible sur le serveur LDAP ou que LDAP n'est pas activé, l'opération NFS peut échouer ou continuer. Dans ces cas, le comportement dépend de l'activation ou non de LDAP pour la cible de montage et de l'accès anonyme pour l'export.

L'accès anonyme est désactivé par défaut. Toute demande NFS associée à un utilisateur introuvable échoue.

Si l'accès anonyme est activé, les demandes associées à un utilisateur introuvable sur le serveur LDAP poursuivent avec les UID de séquence et GID de séquence définis dans les options de l'export. Vous souhaiterez peut-être autoriser l'accès anonyme si le processus de montage utilise un principal Kerberos système qui n'existe pas dans votre serveur LDAP et que les droits écrasés autorisent les quelques opérations en lecture seule utilisées par le client NFS pour monter le système de fichiers.

Scénarios de demande NFS pour les exportations compatibles Kerberos
LDAP activé sur la cible de montage ? Réponse LDAP Accès anonyme activé ? Exportation de squash activée ? Demande NFS
Tout Tout Tout Oui (tout)

Poursuite avec l'UID de séquence et l'GID de séquence définis dans les options de l'export. Aucune liste de groupes secondaires.
Tout Tout Tout Oui (racine)

L'UID de squash et le GID de squash sont définis dans les options de l'export uniquement après une réponse LDAP réussie où le nom d'utilisateur est mappé avec l'UID 0. Aucune liste de groupes secondaires.

Si la réponse LDAP renvoie un UID différent de 0, l'utilisateur, le GID et la liste de groupes sont renvoyés.
Oui Correspondance USERNAME Tout Non Utilise un UID, un GID et une liste de groupes secondaires extraits du serveur LDAP.
Oui Aucune correspondance USERNAME Oui Non Poursuite avec l'UID de séquence et l'GID de séquence définis dans les options de l'export. Aucune liste de groupes secondaires.
Oui Aucune correspondance USERNAME Non Non Echec avec erreur d'autorisations.
Oui Erreur LDAP autre qu'aucun utilisateur correspondant Tout Non Echec avec erreur d'autorisations.
Non Non applicable. Oui Non

Poursuite avec l'UID de séquence et l'GID de séquence définis dans les options de l'export.
Non Non applicable. Non Non Echec avec erreur d'autorisations.
Remarque

Les exports compatibles Kerberos utilisent toujours Utiliser LDAP pour la liste de groupes lorsque l'option Activer LDAP est activée sur la cible de montage.

Pour plus d'informations, reportez-vous à Options d'export NFS.

Prérequis

File Storage nécessite plusieurs prérequis pour utiliser Kerberos pour l'authentification.

Les conditions requises pour utiliser l'authentification Kerberos par utilisateur sont les suivantes :

  • Infrastructure LDAP gérée par le client pour mapper les principaux Kerberos avec les identités UNIX. Pour plus d'informations, reportez-vous à la section LDAP for Authorization prérequis.
  • Infrastructure Kerberos gérée par le client, avec un KDC tel que MIT ou Microsoft Active Directory.
  • Serveur DNS capable de résoudre le nom et l'adresse IP de la cible de montage. Les fonctions de recherche aval et inverse sont requises.
Cette image présente l'infrastructure gérée par le client et OCI nécessaire à l'authentification Kerberos.
  1. Communication avec un serveur KDC géré par le client via le port TCP/UDP 88.
  2. Communication sécurisée avec une cible de montage compatible Kerberos sur le port NFS 2048/2049/2050 (chiffré en option).
  3. Communication avec le service DNS via le port TCP/UDP 53.
  4. Communication avec le service LDAP géré par le client sur le port TCP configuré dans le connecteur sortant. La valeur par défaut est le port TCP 636.
  5. Données cryptées lorsqu'elles sont inactives dans File Storage.

Infrastructure LDAP

File Storage utilise des UID et des GID pour autoriser l'accès aux fichiers. File Storage utilise LDAP pour mettre en correspondance les principaux Kerberos avec les UID et les GIDS. Pour plus d'informations sur la configuration requise pour l'infrastructure LDAP, reportez-vous à la section Prerequisites for using LDAP for Authorization.

Si File Storage ne peut pas rechercher les informations d'autorisation à partir de LDAP, les accès NFS pour le principal Kerberos échoueront probablement. L'authentification Kerberos peut être utilisée sans LDAP, mais tous les principaux Kerberos authentifiés seront traités comme anonymes. Pour plus d'informations, reportez-vous à la section LDAP Lookups and Anonymous Access.

Fichier Keytab Kerberos

Le fichier keytab Kerberos stocké dans OCI Vault doit être un tableau de chaînes encodé en Base64 de la structure suivante : 

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

Chaque entrée du fichier keytab ne peut avoir qu'un seul principal et ce principal doit inclure le nom de domaine qualifié complet de la cible de montage en tant qu'instance. Un principal peut avoir plusieurs entrées avec différents types de chiffrement ou chiffrements.

Par exemple, si nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM est le principal dans le fichier keytab, FSS_EXAMPLE.COM est le domaine, fss_test.com est l'instance et nfs est le domaine principal. Le nom de domaine qualifié complet de la cible de montage dans cet exemple doit être krb_mt1.fss_test.com. Si vous utilisez un serveur DNS géré par le client, vous devez utiliser ce nom de domaine qualifié complet dans les commandes de montage.

Remarque

Lors de l'utilisation du résolveur Internet et VCN par défaut, le service File Storage construit un nom de domaine qualifié complet en combinant le nom d'hôte de la cible de montage avec le nom de domaine qualifié complet du sous-réseau dans lequel se trouve la cible de montage. Après sa création, le nom d'hôte peut être modifié dans la page de détails de la cible de montage. Pour plus d'informations, reportez-vous à Gestion des cibles de montage.

File Storage prend en charge l'ensemble de cryptages suivant :

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

OCI File Storage prend en charge une taille de fichier keytab Kerberos maximale de 1024 octets.
Important

Validez le keytab Kerberos avant d'activer Kerberos pour éviter une interruption de disponibilité causée par un keytab non valide. Vous pouvez valider le fichier keytab lorsque vous configurez ou vérifiez la configuration Kerberos d'une cible de montage.

Lorsque vous validez le fichier keytab Kerberos via la console, la CLI ou l'API, le service File Storage vérifie les éléments suivants :

  • Si la taille du fichier keytab est supérieure à 1024 octets
  • Que le numéro de version du fichier keytab n'est pas 1281 ou 1282
  • Si le fichier keytab contient des entrées NULL
  • Si le fichier keytab a des entrées avec des noms de principal différents
  • Si le fichier keytab contient plus de 12 entrées, ce qui correspond au maximum
  • Si le type d'encodage keytab n'est pas l'un des suivants :
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Remarque

Un fichier keytab extrait du KDC au format binaire doit être converti en Base64, puis utilisé pour créer une clé secrète dans OCI Vault. Veillez à sélectionner Base64 comme format de la clé secrète lorsque vous collez le fichier keytab converti.

File Storage prend en charge la rotation des keytab à l'aide d'un keytab de sauvegarde. Pour plus d'informations, reportez-vous à Rotation des clés.

Remarques et limites

Lorsque vous utilisez Kerberos pour l'authentification File Storage, tenez compte des informations et limites suivantes.

  • Pour l'authentification Kerberos par utilisateur, File Storage nécessite une infrastructure LDAP (Lightweight Directory Access Protocol) gérée par le client, y compris un serveur LDAP prenant en charge un schéma POSIX RFC2307.
  • File Storage prend en charge une taille de fichier keytab Kerberos maximale de 1024 octets.

  • File Storage prend en charge l'ensemble de cryptages suivant :

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • Il n'est pas recommandé de monter des systèmes de fichiers avec les options rsize ou wsize. Si vous fournissez des valeurs pour ces options, elles peuvent être réduites à 256 Ko par File Storage lors de l'utilisation de KRB5I ou KRB5P.
  • Les performances de File Storage lors de l'utilisation du mode d'authentification Kerberos KRB5 équivaut à peu près à l'utilisation de l'authentification AUTH_SYS. Les performances diminuent considérablement lors de l'utilisation de KRB5P et légèrement lors de l'utilisation de KRB5I. Les performances peuvent varier en fonction de la configuration client et du système de fichiers.

Surveillance et alarmes

Il est important de connaître rapidement un problème lorsque vous utilisez l'authentification Kerberos avec l'autorisation LDAP. Si l'infrastructure Kerberos ou LDAP ne fonctionne pas correctement, les clients NFS risquent de perdre l'accès aux systèmes de fichiers File Storage mis à disposition via ses exports. Pour repérer de tels problèmes, nous vous recommandons de définir des alarmes sur des mesures de cible de montage. Les alarmes peuvent vous alerter de problèmes d'infrastructure en quelques minutes.

Les alarmes créées à partir des erreurs Kerberos, des erreurs de connexion LDAP et des erreurs de demande LDAP détectent les problèmes de connectivité entre les cibles de montage, les connecteurs sortants et l'infrastructure LDAP gérée par le client.

L'exemple de requête suivant peut être utilisé pour créer une alarme pour les erreurs Kerberos :

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

L'exemple de requête suivant peut être utilisé pour créer une alarme pour la connectivité LDAP :

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

Pour plus d'informations sur la surveillance des mesures et l'utilisation des alarmes, reportez-vous à Présentation de Monitoring. Pour plus d'informations sur les notifications relatives aux alarmes, reportez-vous à Présentation de Notifications.

Stratégie IAM requise

File Storage doit accéder au mot de passe du serveur LDAP et aux clés secrètes de coffre Kerberos de la cible de montage pour la configuration Kerberos. L'utilisateur qui configure la cible de montage et la cible de montage elle-même ont besoin d'un accès en lecture.

Stratégie de gestion des clés secrètes de coffre

Accordez à l'utilisateur ou au groupe qui crée les droits d'accès de clé secrète Vault. Pour plus d'informations, reportez-vous à Gestion des clés secrètes Vault.

Stratégie permettant d'activer la configuration de la cible de montage

Accordez à l'utilisateur ou au groupe configurant Kerberos et LDAP sur une cible de montage des autorisations à l'aide d'une stratégie telle que la suivante :

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> }

Cela permet à l'utilisateur d'émettre des commandes File Storage qui lisent les clés secrètes Vault et affichent des parties de la clé secrète pour validation. File Storage présente le principal, le numéro de version de clé et les types de cryptage à l'utilisateur qui configure la cible de montage pour validation.

Stratégie permettant à une cible de montage d'extraire des clés secrètes

Le service File Storage nécessite la possibilité de lire les clés secrètes. File Storage utilise des principaux de ressource pour accorder à un ensemble spécifique de cibles de montage l'accès à la clé secrète du coffre. Il s'agit d'un processus en deux étapes, d'abord les cibles de montage nécessitant un accès doivent être placées dans un groupe dynamique, puis le groupe dynamique est autorisé à lire les clés secrètes.

  1. Créez un groupe dynamique pour les cibles de montage avec une stratégie telle que la suivante :

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

    Si le groupe dynamique contient plusieurs règles, veillez à utiliser l'option Match any rules defined below.

  2. Créez une stratégie IAM qui donne au groupe dynamique de cibles de montage un accès en lecture aux clés secrètes Vault :

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