4. Préparer le déploiement des services

Phrase d'intro

4.1. Planifier les noms de services

Pour mutualiser les services tout en respectant le principe de moindre privilège, vous devez définir des noms spécifiques.

Q1.

Pourquoi utiliser des noms de service distincts NFSv4 et LDAP sur le même système ?

Il est essentiel d'émettre des identités distinctes pour les deux fonctions de sécurité :

  • Deux principals Kerberos distincts :

    • nfs/nfs-srvr.lab.local@LAB.LOCAL

    • ldap/ldap-srvr.lab.local@LAB.LOCAL

  • Si deux certificats X509 distincts sont signés par la même autorité, la maquette peut être transposée à un déploiement multi-hôtes ultérieurement.

Q2.

Comment assurer une résolution locale des noms d'hôtes pour le client et le serveur ?

Consultez les pages de manuel de la table de recherche statique des noms d'hôtes : man hosts.

Créez un script qui ajoute les enregistrements du client et du serveur dans le fichier /etc/hosts, tout en évitant les doublons.

Copiez l'exemple de code ci-dessous dans le fichier update-hosts.sh.

[Attention] Attention

Éditez le script pour utiliser vos adresses IPv4 et IPv6.

#!/usr/bin/env bash

set -euo pipefail

DOMAIN="lab.local"
HOSTS_FILE="/etc/hosts"

CLIENT_IPS=(
        "172.28.101.6"
        "2001:678:3fc:65:baad:caff:fefe:6"
)
CLIENT_NAME="clnt"

SERVER_IPS=(
        "172.28.101.5"
        "2001:678:3fc:65:baad:caff:fefe:5"
)
SERVER_NAME="srvr"
SERVER_ALIASES="ldap-srvr.${DOMAIN} nfs-srvr.${DOMAIN}"

if [[ ${EUID} -ne 0 ]]; then
        echo "This script must be run as root." >&2
        exit 1
fi

escape_sed_bre() {
        sed 's/[][\\.^$*]/\\&/g'
}

update_host_entry() {
        local ip="$1"
        local name="$2"
        local extra_aliases="${3-}"
        local escaped_ip
        escaped_ip=$(printf '%s\n' "${ip}" | escape_sed_bre)
        sed -i "/^${escaped_ip}[[:space:]]/d" "${HOSTS_FILE}"
        if [[ -n ${extra_aliases} ]]; then
                echo "${ip} ${name}.${DOMAIN} ${name} ${extra_aliases}" >>"${HOSTS_FILE}"
        else
                echo "${ip} ${name}.${DOMAIN} ${name}" >>"${HOSTS_FILE}"
        fi
}

for ip in "${CLIENT_IPS[@]}"; do
        update_host_entry "${ip}" "${CLIENT_NAME}"
done

for ip in "${SERVER_IPS[@]}"; do
        update_host_entry "${ip}" "${SERVER_NAME}" "${SERVER_ALIASES}"
done

exit 0

Lancez le script sur le client et sur le serveur.

sudo bash update-hosts.sh

Testez la résolution locale des noms depuis le client.

host ldap-srvr.lab.local
ldap-srvr.lab.local is an alias for srvr.lab.local.
srvr.lab.local has address 172.28.101.5
srvr.lab.local has IPv6 address 2001:678:3fc:65:baad:caff:fefe:5
host nfs-srvr.lab.local
nfs-srvr.lab.local is an alias for srvr.lab.local.
srvr.lab.local has address 172.28.101.5
srvr.lab.local has IPv6 address 2001:678:3fc:65:baad:caff:fefe:5
for ip in 172.28.101.5 2001:678:3fc:65:baad:caff:fefe:5; do
    host $ip
done
5.101.28.172.in-addr.arpa domain name pointer srvr.lab.local.
5.101.28.172.in-addr.arpa domain name pointer srvr.
5.101.28.172.in-addr.arpa domain name pointer nfs-srvr.lab.local.
5.101.28.172.in-addr.arpa domain name pointer ldap-srvr.lab.local.
5.0.0.0.e.f.e.f.f.f.a.c.d.a.a.b.5.6.0.0.c.f.3.0.8.7.6.0.1.0.0.2.ip6.arpa domain name pointer srvr.lab.local.
5.0.0.0.e.f.e.f.f.f.a.c.d.a.a.b.5.6.0.0.c.f.3.0.8.7.6.0.1.0.0.2.ip6.arpa domain name pointer srvr.
5.0.0.0.e.f.e.f.f.f.a.c.d.a.a.b.5.6.0.0.c.f.3.0.8.7.6.0.1.0.0.2.ip6.arpa domain name pointer nfs-srvr.lab.local.
5.0.0.0.e.f.e.f.f.f.a.c.d.a.a.b.5.6.0.0.c.f.3.0.8.7.6.0.1.0.0.2.ip6.arpa domain name pointer ldap-srvr.lab.local.

Q3.

Quelles sont les conséquences de l'utilisation de deux noms de service pour résoudre deux principaux Kerberos vers la même adresse IP ?

Le démon slapd n’expose pas le même keytab que le démon nfs-kernel-server.

Chaque service charge son principal depuis son fichier >keytab (par défaut : /etc/krb5.keytab pour NFS et /etc/ldap/ldap.keytab pour LDAP). Les deux services peuvent ainsi cohabiter sur le même hôte sans partager leurs clés cryptographiques, ce qui respecte le principe de moindre privilège.

4.2. Configurer l'autorité de certification

Pour mutualiser la gestion des certificats, vous devez définir une CA commune aux deux services.

Q4.

L'autorité de certification OpenSSL générée pour le service NFS peut-elle être réutilisée pour le service LDAP ?

C’est précisément l'un des objectifs de la mutualisation. Une seule clé privée d’autorité (labCA.key) signe successivement deux paires (certificat, clé) : l'une pour nfs-server.lab.local, l'autre pour ldap-server.lab.local. Les clients (NFS et LDAP) n'ont alors qu'un seul fichier, labCA.crt, à installer en trust anchor dans /usr/local/share/ca-certificates/ puis à régénérer via update-ca-certificates.

Q5.

Comment répartir les certificats et les clés privées associées sur le serveur et le client ?

Proposez un tableau respectant la règle selon laquelle chaque extrémité de la session TLS détient sa propre clé privée, tandis que les certificats publics (y compris celui de l'autorité) sont partagés.

Tableau 3. Répartition des certificats et des clés privées pour les services LDAP et NFS mutualisés

Fichier Serveur : srvr.lab.local Client : clnt.lab.local
Autorité de certification commune
labCA.crt
Racine de confiance commune
Démon slapd : /etc/ldap/certs/labCA.crt (olcTLSCACertificateFile)
Démon tlshd : /etc/tlshd.d/labCA.crt
Racine de confiance commune
Démon nslcd : /etc/ssl/certs/labCA.crt (tls_cacertfile)
Démon tlshd : /etc/tlshd.d/labCA.crt
Magasin système : /usr/local/share/ca-certificates/labCA.crt
Certificats et clés du service LDAP (algorithme Ed25519 — handshake OpenSSL espace utilisateur via slapd / nslcd)
ldap-srvr.crt /etc/ldap/certs/ldap-srvr.crt (olcTLSCertificateFile) /etc/ssl/certs/ldap-srvr.crt (vérification du serveur par nslcd)
ldap-srvr.key /etc/ldap/certs/ldap-srvr.key (olcTLSCertificateKeyFile — propriétaire openldap, mode 400)
ldap-clnt.crt (non requis côté serveur) /etc/ssl/certs/ldap-clnt.crt (tls_cert dans nslcd.conf)
ldap-clnt.key /etc/ssl/private/ldap-clnt.key (tls_key dans nslcd.conf — propriétaire nslcd, mode 400)
Certificats et clés du service NFS (algorithme RSA 4096 — chiffrement kTLS noyau via tlshd)
nfs-srvr.crt /etc/tlshd.d/nfs-srvr.crt (x509.certificate dans tlshd.conf) /etc/tlshd.d/nfs-srvr.crt (vérification du serveur NFS par tlshd)
nfs-srvr.key /etc/tlshd.d/nfs-srvr.key (x509.private_key dans tlshd.conf — propriétaire root, mode 400)
nfs-clnt.crt (non requis côté serveur) /etc/tlshd.d/nfs-clnt.crt (x509.certificate dans tlshd.conf)
nfs-clnt.key /etc/tlshd.d/nfs-clnt.key (x509.private_key dans tlshd.conf — propriétaire root, mode 400)