Aujourd’hui, je vais aborder l’intégration de CockroachDB Active Directory. Sous les couvertures, Cockroach utilise GSSAPI. Aujourd’hui, Cockroach ne prend en charge que la cartographie des utilisateurs. Il ne prend pas en charge la synchronisation des utilisateurs entre l’unité d’organisation AD et un rôle de cafard.
Mon environnement de laboratoire se compose d’un contrôleur AD exécutant Windows Server 2016 en tant que VM VirtualBox et d’une VM Vagrant avec CentOS 7 hébergeant CockroachDB. Les machines virtuelles partagent un réseau hôte uniquement. Cela était essentiel dans ma configuration afin que mon nœud Cockroach puisse interagir avec AD sur le port 88.
Conditions:
- Contrôleur de domaine Active Directory
- OS Linux, dans mon cas RHEL7 et CockroachDB 20.1.1.
Conditions préalables:
- J’utilise une évaluation de Windows Server 2016. Vous pouvez trouver un essai de 180 jours ici.
- J’ai suivi ce tutoriel pour installer Windows Server dans VirtualBox dans le cadre d’une installation personnalisée.
- Installez VirtualBox Guest Additions en suivant ce didacticiel.
- Partagez un répertoire avec AD et l’hôte. Vous en aurez besoin pour copier les keytabs sur les nœuds Cockroach.
- Remplacez le nom d’hôte de la machine AD par un nom convivial. j’utilise serveur publicitaire comme mon nom d’hôte.
- L’heure, la date et le fuseau horaire doivent être synchronisés sur le serveur AD et les nœuds Cockroach. Cela va sans dire puisque nous travaillons avec Kerberos, mais cela vaut toujours la peine d’être mentionné.
- Remplacez l’IP Windows par le même sous-réseau que le(s) nœud(s) CockroachDB.
- Ajoutez les nœuds Cockroach au fichier des hôtes Windows (facultatif).
- Installez le contrôleur de domaine Active Directory en suivant ce didacticiel.
Je fournis les images suivantes comme points de référence, les didacticiels ci-dessus devraient vous amener au résultat souhaité.
Installation du serveur Windows
Modification du nom d’hôte Windows
Vérifiez que le nouveau nom d’hôte est en vigueur
Synchroniser l’heure, la date, le fuseau horaire
Modifier le sous-réseau AD pour qu’il corresponde à CockroachDB
En option, ajoutez des hôtes CockroachDB au fichier d’hôtes du serveur AD :
À ce stade, vous devriez pouvoir envoyer un ping à l’hôte CentOS.
Il en va de même depuis la machine CentOS, une fois le fichier /etc/hosts renseigné.
127.0.0.1 node.example.com node 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.33.15 adserver.example.com adserver
[vagrant@node ~]$ ping adserver.example.com PING adserver.example.com (192.168.33.15) 56(84) bytes of data. 64 bytes from adserver.example.com (192.168.33.15): icmp_seq=1 ttl=128 time=0.369 ms 64 bytes from adserver.example.com (192.168.33.15): icmp_seq=2 ttl=128 time=0.511 ms 64 bytes from adserver.example.com (192.168.33.15): icmp_seq=3 ttl=128 time=0.430 ms
Pour vérifier l’intégrité, assurons-nous que nous avons une connectivité au serveur AD sur le port 88. Nous aurons besoin d’un package telnet installé.
sudo yum install -y telnet
telnet adserver.example.com 88
Trying 192.168.33.15... Connected to adserver.example.com. Escape character is '^]'.
Nous pouvons maintenant nous concentrer sur l’ajout d’un principal de service dans AD. Générez un keytab et configurez le fichier krb5.conf sur la machine CentOS.
Sur la machine AD Controller, accédez à la console Utilisateurs et ordinateurs Active Directory.
Ajoutez un nouvel utilisateur en cliquant avec le bouton droit sur les utilisateurs sous votre domaine ; dans mon cas, .
Enfin, sélectionnez vos préférences de mot de passe et cliquez sur Terminer.
Il est également important de vérifier les deux propriétés spécifiques à Kerberos suivantes pour l’utilisateur. J’ai été confus par l’interface utilisateur de Windows Server sur l’emplacement de ces propriétés. Vous pouvez les trouver sur la page des propriétés de l’utilisateur, sous l’onglet Compte. Vous devrez peut-être faire défiler jusqu’en bas dans la zone de case à cocher pour trouver ces propriétés répertoriées.
Cliquez sur Appliquer pour terminer cette étape.
À ce stade, nous pouvons associer le nom du principal du service et générer un keytab. Nous pouvons utiliser le shell CMD ou PowerShell pour la tâche. ktpass l’utilitaire dans AD nous aidera avec cela.
ktpass -out node.keytab -princ postgres/node.example.com@EXAMPLE.COM -mapUser pguser@EXAMPLE.COM -mapOp set -pType KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -pass CRDB123?
Cette commande génère un fichier keytab appelé node.keytab, associant le nom du principal de service postgres à un FQDN du nœud Cockroach node.example.com@EXAMPLE.COM, et mapper l’utilisateur AD pguser au SPN. nous précisons AES256-SHA1 crypto et enfin, nous passons le mot de passe au SPN nouvellement créé.
Générer Keytab et associer un SPN à un principal
On peut aussi valider le SPN avec la commande suivante :
setspn -l pguser
À ce stade, nous avons un keytab que nous pouvons utiliser pour nous connecter à l’AD à partir de notre machine CentOS. Copiez le keytab sur les hôtes Cockroach.
Maintenant, sur les hôtes CentOS, nous devons effectuer quelques étapes préliminaires pour intégrer AD. Pour commencer, nous devons nous assurer que l’heure, la date et le fuseau horaire sont exacts.
timedatectl timedatectl list-timezones | grep New_York
[vagrant@node ~]$ timedatectl
Local time: Wed 2020-06-03 17:00:01 UTC
Universal time: Wed 2020-06-03 17:00:01 UTC
RTC time: Wed 2020-06-03 16:59:59
Time zone: UTC (UTC, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
[vagrant@node ~]$ timedatectl list-timezones | grep New_York
America/New_York
[vagrant@node ~]$ sudo timedatectl set-timezone America/New_York
[vagrant@node ~]$ timedatectl
Local time: Wed 2020-06-03 13:01:06 EDT
Universal time: Wed 2020-06-03 17:01:06 UTC
RTC time: Wed 2020-06-03 17:01:05
Time zone: America/New_York (EDT, -0400)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2020-03-08 01:59:59 EST
Sun 2020-03-08 03:00:00 EDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2020-11-01 01:59:59 EDT
Sun 2020-11-01 01:00:00 EST
Installer krb5-workstation package et remplissez avec les propriétés spécifiques à AD.
yum install -y krb5-workstation
Configurer /etc/krb5.conf fichier avec les propriétés suivantes :
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = adserver.example.com
admin_server = adserver.example.com
default_domain = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Modifiez les autorisations sur le keytab.
chmod 600 node.keytab
Met le KRB5_KTNAME variable à l’emplacement du keytab.
export KRB5_KTNAME=node.keytab
À ce stade, nous devrions être en mesure de nous authentifier auprès d’AD en tant que pguser.
[vagrant@node ~]$ kinit pguser
Password for pguser@EXAMPLE.COM:
[vagrant@node ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: pguser@EXAMPLE.COM
Valid starting Expires Service principal
06/03/2020 13:23:06 06/03/2020 23:23:06 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 06/04/2020 13:23:06
Vérifions quelques autres choses à propos de notre keytab, car ces choses peuvent vous éviter de nombreuses heures de douleur. Croyez-moi, je sais!
Kerberos exige que KVNO nombre pour un principal sur un système basé sur Unix soit supérieur ou égal à 3. Nous pouvons le confirmer avec la commande suivante :
kvno pguser@EXAMPLE.COM
pguser@EXAMPLE.COM: kvno = 3
Vérifions si le SPN KVNO correspond au principal.
kvno postgres/node.example.com@EXAMPLE.COM
[vagrant@node ~]$ kvno postgres/node.example.com@EXAMPLE.COM postgres/node.example.com@EXAMPLE.COM: kvno = 3
Nous pouvons également valider que notre entrée keytab correspond à ce qui précède :
[vagrant@node ~]$ klist -kt node.keytab Keytab name: FILE:node.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 3 12/31/1969 19:00:00 postgres/node.example.com@EXAMPLE.COM
Nous pouvons également utiliser ktutil pour confirmer la même chose :
[vagrant@node ~]$ ktutil ktutil: read_kt node.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 postgres/node.example.com@EXAMPLE.COM
Même si nous avons déjà vérifié les deux KVNO, soyons absolument sûrs et vérifions la même chose sur notre serveur AD.
Dans PowerShell, exécutez la commande ci-dessous pour obtenir la valeur KVNO.
Get-ADUser pguser -property msDS-KeyVersionNumber
Comme ils correspondent tous, nous pouvons procéder à la configuration de GSSAPI avec Cockroach.
Installez CockroachDB.
COCKROACH_VERSION=v21.2.0 wget -qO- https://binaries.cockroachdb.com/cockroach-$COCKROACH_VERSION.linux-amd64.tgz | tar xvz sudo cp -i cockroach-$COCKROACH_VERSION.linux-amd64/cockroach /usr/local/bin/ cockroach version
Build Tag: v21.2.0 Build Time: 2021/11/15 14:00:58 Distribution: CCL Platform: linux amd64 (x86_64-unknown-linux-gnu) Go Version: go1.16.6 C Compiler: Clang 10.0.0 Build SHA-1: 6123c0c73ff0eea223cfd25e1e557648413126f8 Build Type: release
Démarrez un cluster sécurisé.
Générer des certificats : cette étape n’est pas différente de celle des documents. Je ne fais que passer des noms DNS supplémentaires à la commande certs.
HOSTNAME="node.example.com node 192.168.33.10" mkdir certs my-safe-directory cockroach cert create-ca --certs-dir=certs --ca-key=my-safe-directory/ca.key cockroach cert create-node $HOSTNAME --certs-dir=certs --ca-key=my-safe-directory/ca.key openssl x509 -in certs/node.crt -text | grep "Subject Alternative Name" -A 1 cockroach cert create-client root --certs-dir=certs --ca-key=my-safe-directory/ca.key
[vagrant@node ~]$ openssl x509 -in certs/node.crt -text | grep "Subject Alternative Name" -A 1
X509v3 Subject Alternative Name:
DNS:node.example.com, DNS:node, IP Address:192.168.33.10
Démarrez le cafard en mode sécurisé.
cockroach start --certs-dir=certs --store=node1 --listen-addr=node.example.com:26257 --http-addr=node.example.com:8080 --join=node.example.com:26257,node.example.com:26258,node.example.com:26259 --background cockroach start --certs-dir=certs --store=node2 --listen-addr=node.example.com:26258 --http-addr=node.example.com:8081 --join=node.example.com:26257,node.example.com:26258,node.example.com:26259 --background cockroach start --certs-dir=certs --store=node3 --listen-addr=node.example.com:26259 --http-addr=node.example.com:8082 --join=node.example.com:26257,node.example.com:26258,node.example.com:26259 --background
Initialisez le cluster.
[vagrant@node ~]$ cockroach init --certs-dir=certs --host=node.example.com:26257 Cluster successfully initialized
Connectez-vous à la base de données.
cockroach sql --certs-dir=certs --host=node.example.com
Activer la licence d’entreprise. GSSAPI est une fonctionnalité d’entreprise au moment de la rédaction de cet article.
SET CLUSTER SETTING cluster.organization = 'Acme Company'; SET CLUSTER SETTING enterprise.license="xxxxxxxxxxxx";
Activez GSSAPI. Cela activera GSSAPI pour tout le monde sauf l’utilisateur root. L’utilisateur racine s’appuiera toujours sur le certificat racine pour se connecter.
SET cluster setting server.host_based_authentication.configuration = 'host all all all gss include_realm=0';
Créez un utilisateur normal et accordez des privilèges.
CREATE USER pguser; GRANT ALL ON DATABASE defaultdb TO pguser; q
Il ne reste plus qu’à kinit comme pguser. N’oubliez pas que nous l’avons déjà fait, mais reprenons cette étape pour être complet.
kdestroy -A kinit pguser klist
Enfin, nous devons installer psql client en tant que cockroach.CLI ne prend pas en charge GSSAPI.
J’aimerais utiliser la version 9.5 du client psql car c’est le protocole filaire actuellement pris en charge pour CockroachDB. Malheureusement, CentOS 7 est livré avec la version 9.2 prête à l’emploi, et nous allons suivre les étapes de ce lien pour installer la bonne version.
Désactiver postgresq dans le [base] et [updates] sections du fichier /etc/yum.repos.d/CentOS-Base.repo avec…