{"id":1109,"date":"2021-07-15T14:33:29","date_gmt":"2021-07-15T12:33:29","guid":{"rendered":"https:\/\/loeilduse.fr\/?p=1109"},"modified":"2021-07-15T16:12:54","modified_gmt":"2021-07-15T14:12:54","slug":"creer-un-certificat-auto-signe-ldaps-pour-pinniped","status":"publish","type":"post","link":"https:\/\/loeilduse.fr\/?p=1109&lang=fr","title":{"rendered":"Cr\u00e9er un certificat auto-sign\u00e9 LDAPS pour Pinniped"},"content":{"rendered":"

Afin de simplifier l\u2019authentification des clusters Kubernetes fonctionnant sur diff\u00e9rents clouds, VMware a d\u00e9velopp\u00e9 le projet Pinniped<\/a> accessible en Opensource. Pinniped a \u00e9t\u00e9 int\u00e9gr\u00e9 par d\u00e9faut dans l\u2019offre VMware Tanzu Kubernetes Grid<\/a> (TKG) depuis la version 1.3 \u00a0en remplacement de l\u2019extension Gangway<\/a>. Pinniped permet l’authentification \u00e0 partir de sources OIDC ou LDAP. Dans le cas de source LDAP, Pinniped ne se connecte pas directement \u00e0 LDAP mais s\u2019appuie pour le moment sur le composant Dex<\/a> comme le faisait d\u00e9j\u00e0 Gangway.<\/span><\/p>\n

Lorsqu\u2019un utilisateur ex\u00e9cute une commande Kubernetes pour la premi\u00e8re fois ou apr\u00e8s une certaine p\u00e9riode d\u2019inactivit\u00e9, il est invit\u00e9 \u00e0 s\u2019authentifier une seule fois avec son ses identifiants d\u2019entreprise et peut ensuite consommer plusieurs cluster Kubernetes.<\/span><\/p>\n

J\u2019ai voulu tester cette fonctionnalit\u00e9 dans mon lab avec un serveur LDAPS\/Active Directory sous Windows 2019 et je me suis vite confront\u00e9 \u00e0 l\u2019\u00e9ternel probl\u00e8me de certificat non sign\u00e9s par une autorit\u00e9 connue. Il fallait donc que je cr\u00e9\u00e9 un certificat qui soit reconnu par le serveur Active Directory. En cherchant des heures sur Internet, j\u2019ai fini par trouver un article (en Anglais) de Peter Mescalchin<\/a> qui a fonctionn\u00e9 du premier coup\u00a0: Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers. – bl.ocks.org.<\/a><\/span><\/p>\n

Cependant, quand j\u2019ai voulu utiliser cette proc\u00e9dure avec Pinniped, \u00e7a n\u2019a pas fonctionn\u00e9 car les informations SAN (Subject Alternative Name) n\u2019\u00e9taient pas pr\u00e9sentes dans le certificat. En croisant plusieurs articles sur le sujet, j\u2019ai pu adapter la solution de Peter Mescalchin afin que les certificats int\u00e8grent les informations SAN. Ca donne ceci\u00a0:<\/span><\/p>\n

Cr\u00e9ation du certificat Root<\/strong><\/span><\/p>\n

Via OpenSSL<\/span> <\/em>(j\u2019ai utilis\u00e9 un Linux Ubuntu) cr\u00e9er une cl\u00e9 priv\u00e9e (ca.key<\/span> dans mon exemple) pour pouvoir ensuite cr\u00e9er le certificat root (ca.crt<\/span> dans mon exemple). La premi\u00e8re commande vous demandera un mot de passe et la seconde des renseignements sur votre organisation.<\/span><\/p>\n

$ openssl genrsa -aes256 -out ca.key 4096
\n<\/em><\/span>$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt<\/em><\/span><\/p>\n

\u00a0<\/strong><\/span>Importer le certificat Root sur le serveur AD<\/strong><\/span><\/p>\n

A partir du serveur AD, tapez la commande certlm<\/span> <\/em>ou via Control Pannel, tapez computer certificates dans la barre de recherche\u00a0:<\/span><\/p>\n

Attention \u00e0 bien choisir \u201cManage computer certificates\u201d et non \u201cManage user certificates\u00a0\u00bb<\/span><\/p>\n

\"\"<\/p>\n

Importez le ca.crt<\/span><\/em> pr\u00e9c\u00e9demment g\u00e9n\u00e9r\u00e9 dans la partie \u00ab\u00a0Trusted Root Certification Authorities\\Certificates\u00a0\u00bb<\/span><\/p>\n

\"\"<\/p>\n

\u00a0<\/strong><\/span><\/p>\n

Cr\u00e9ation du certificat Client<\/strong><\/span><\/p>\n

Toujours \u00e0 partir du serveur Active Directory, cr\u00e9er un fichier, dans notre exemple il porte le nom request.inf<\/span><\/em>. En rouge, j\u2019ai apport\u00e9 les modifications par rapport \u00e0 la proc\u00e9dure initiale afin d\u2019y ajouter les informations SAN. Attention \u00e0 bien mettre dans CN<\/span> <\/em>le FQDN du serveur AD.<\/span><\/p>\n

Les valeurs de _continue_=\u00a0\u00ab\u00a0dns\u00a0\u00bb<\/em><\/strong><\/span> et _continue_=\u00a0\u00ab\u00a0ip-address\u00a0\u00bb<\/em> <\/strong><\/span>correspondent aux valeurs SAN, les autres valeurs possibles pour r\u00e9f\u00e9rencer le serveur AD.<\/span><\/p>\n

[<\/em>Version<\/em>]
\n<\/em>Signature=”$Windows NT$”<\/em><\/span><\/p>\n

[NewRequest]
\n<\/em>Subject = “CN=<\/span><\/em>ad-server.cpod-velocity.az-fkd.cloud-garage.net<\/em><\/strong><\/span>“<\/span>
\n<\/em><\/span>KeySpec = 1
\n<\/em><\/span>KeyLength = 2048
\n<\/em><\/span>Exportable = TRUE
\n<\/em><\/span>MachineKeySet = TRUE
\n<\/em><\/span>SMIME = FALSE
\n<\/em><\/span>PrivateKeyArchive = FALSE
\n<\/em><\/span>UserProtected = FALSE
\n<\/em><\/span>UseExistingKeySet = FALSE
\n<\/em><\/span>ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
\n<\/em><\/span>ProviderType = 12
\n<\/em><\/span>RequestType = PKCS10
\n<\/em><\/span>KeyUsage = 0xa0<\/em><\/span><\/p>\n

[EnhancedKeyUsageExtension]
\n<\/em><\/span>OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication<\/em><\/span><\/p>\n

[Extensions]
\n<\/em><\/strong><\/span>; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
\n<\/em><\/strong><\/span>2.5.29.17 = “{text}”
\n<\/em><\/strong><\/span>_continue_ = “dns=ad-server&”
\n<\/em><\/strong><\/span>_continue_ = “dns=ad-server.cpod-velocity.az-fkd.cloud-garage.net&”
\n<\/em><\/strong><\/span>_continue_ = “dns=cloud-garage.net&”
\n<\/em><\/strong><\/span>_continue_ = “ipaddress=172.17.13.9&”<\/em><\/strong><\/span><\/span><\/p>\n

 <\/p>\n

G\u00e9n\u00e9rer le fichier client.csr<\/em> avec la commande ci-dessous<\/span><\/p>\n

c:\\> certreq -new request.inf client.csr<\/span><\/em><\/p>\n

A partir de la machine Linux\u00a0:<\/span><\/p>\n

Cr\u00e9er un fichier d\u2019extension, dans notre exemple, il porte le nom de v3ext.txt<\/em><\/span>. En rouge, j\u2019ai apport\u00e9 les modifications par rapport \u00e0 la proc\u00e9dure initiale afin d\u2019y ajouter les informations SAN sous la rubrique v3_ca<\/span><\/em> qui sera r\u00e9f\u00e9renc\u00e9 dans la prochaine commande.<\/span><\/p>\n

keyUsage=digitalSignature,keyEncipherment
\n<\/em>extendedKeyUsage=serverAuth
\n<\/em>subjectKeyIdentifier=hash<\/em><\/span><\/p>\n

\u00a0<\/em># These extensions are added when ‘ca’ signs a request.
\n<\/em><\/strong>[ v3_ca ]
\n<\/em><\/strong>subjectAltName = @alt_names<\/em><\/strong><\/span><\/p>\n

[ alt_names ]
\n<\/em><\/strong>DNS.1 = ad-server.cpod-velocity.az-fkd.cloud-garage.net
\n<\/em><\/strong>DNS.2 = ad-server
\n<\/em><\/strong>IP.1 = 172.17.13.9<\/em><\/strong><\/span><\/p>\n

Toujours \u00e0 partir de la machine Linux, cr\u00e9er le certificat client.crt<\/em> \u00e0 partir des fichiers g\u00e9n\u00e9r\u00e9s dans les \u00e9tapes pr\u00e9c\u00e9dentes ca.crt, ca.key, client.csr et v3ext.txt<\/em> en rouge ce qui a \u00e9t\u00e9 rajout\u00e9 par rapport \u00e0 la commande issue de la proc\u00e9dure initiale<\/span><\/p>\n

$ openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out client.crt<\/em> -extensions v3_ca<\/strong><\/em><\/span><\/span><\/p>\n

\u00a0<\/em><\/span><\/p>\n

Pour v\u00e9rifier la pr\u00e9sence des informations SAN<\/span><\/p>\n

$ openssl x509 -in client.crt -text
\n<\/em><\/span><\/span>\u00a0…..
\n<\/em><\/span>X509v3 extensions:
\n<\/em><\/strong><\/span><\/span>\u00a0\u00a0\u00a0 \u00a0\u00a0<\/em><\/strong>X509v3 Subject Alternative Name:
\n<\/em><\/strong><\/span>\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DNS:ad-server.cpod-velocity.az-fkd.cloud-garage.net, DNS:ad-server, IP Address:172.17.13.9<\/em><\/strong><\/span><\/p>\n

\u00a0<\/strong><\/span><\/p>\n

Importer le certificat Client<\/strong><\/span><\/p>\n

A partir du serveur AD<\/span><\/p>\n

C:\\> certreq -accept client.crt<\/em><\/span><\/p>\n

Le certificat devrait ainsi appara\u00eetre dans \u00ab\u00a0Personal\\Certificates\u00a0\u00bb<\/span><\/p>\n

\"\"<\/p>\n

Pour que le certificat soit pris en compte, il faut soit red\u00e9marrer le serveur AD ou forcer LDAPS \u00e0 charger le certificat avec la proc\u00e9dure ci-dessous\u00a0:<\/p>\n

Toujours \u00e0 partir du serveur AD, cr\u00e9er un fichier text, dans notre exemple il se nome ldap-renewservercert.txt<\/em> avec le contenu ci-dessous (attention la fin du fichier comprend une ligne avec un \u2013 (un tiret) :<\/span><\/p>\n

dn:
\n<\/em>changetype: modify
\n<\/em><\/span>add: renewServerCertificate
\n<\/em><\/span>renewServerCertificate: 1
\n<\/em><\/span>–<\/em><\/span><\/p>\n

Puis tappez la commande ci-dessous :<\/span><\/p>\n

c:\\> ldifde -i -f ldap-renewservercert.txt<\/em><\/span><\/p>\n

Pour tester la prise en compte<\/span><\/p>\n

Utilisez l\u2019utilitaire ldp.exe<\/em><\/span> en s\u00e9lectionnant le port 636 (ou un autre s’il est sp\u00e9cifique) et en cochant la case SSL.<\/span><\/p>\n

\"\"<\/p>\n

Une fois toute la proc\u00e9dure effectu\u00e9e, il faut r\u00e9cup\u00e9rer le ca.crt<\/span> g\u00e9n\u00e9r\u00e9 \u00e0 la premi\u00e8re \u00e9tape pour le donner \u00e0 Pinniped. Cela peut se faire soit au moment de la cr\u00e9ation du cluster de management TKG ou soit \u00e0 post\u00e9riori.<\/span><\/p>\n

Si le cluster de management n’a pas encore \u00e9tait cr\u00e9\u00e9 :<\/span><\/strong><\/span><\/p>\n

$ tanzu management-cluster create –ui
\n(il y a deux tirets avant l’argument ui mais WordPress n’en n’affiche qu’un seul)
\n<\/em><\/span><\/p>\n

Dans mon test j\u2019ai choisi vSphere comme plate-forme, \u00e0 l\u2019\u00e9tape identity manager il faudra copier le certificat dans la partie ROOT CA<\/span><\/p>\n

\"\"<\/u><\/span><\/p>\n

 <\/p>\n

Si le cluster de management TKG a d\u00e9j\u00e0 \u00e9tait cr\u00e9\u00e9 et que vous souhaitez le mettre \u00e0 jour\u00a0:<\/span><\/strong><\/span><\/p>\n

A partir du contexte Kubernetes du cluster de manager, chiffrez le certificat Root du serveur AD avec la commande base64<\/span> et r\u00e9cup\u00e9rez le r\u00e9sultat :<\/span><\/p>\n

$ base64 -w 0 ca.crt<\/em><\/span><\/p>\n

Modifier le certificat dans la configmap dex<\/span> <\/em>par le r\u00e9sultat de la commande pr\u00e9c\u00e9dente\u00a0:<\/span><\/p>\n

$ kubectl edit configmap -n tanzu-system-auth dex<\/span>
\n<\/em><\/span># Please edit the object below. Lines beginning with a ‘#’ will be ignored,
\n<\/em><\/span># and an empty file will abort the edit. If an error occurs while saving this file will be
\n<\/em><\/span># reopened with the relevant failures.
\n<\/em><\/span>#
\n<\/em><\/span>apiVersion: v1
\n<\/em><\/span>data:
\n<\/em><\/span>\u00a0 config.yaml: |
\n<\/em><\/span>\u00a0\u00a0\u00a0 issuer: https:\/\/172.17.13.10:30167
\n<\/em><\/span>\u00a0\u00a0\u00a0 frontend:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 theme: tkg
\n<\/em><\/span>\u00a0\u00a0\u00a0 <\/em>web:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 https: 0.0.0.0:5556
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tlsCert: \/etc\/dex\/tls\/tls.crt
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tlsKey: \/etc\/dex\/tls\/tls.key
\n<\/em><\/span>\u00a0\u00a0\u00a0 <\/em>expiry:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 signingKeys: 90m
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 idTokens: 5m
\n<\/em><\/span>\u00a0\u00a0\u00a0 logger:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 level: info
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 format: json
\n<\/em><\/span>\u00a0\u00a0\u00a0 staticClients:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – id: pinniped-client-id
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name: pinniped-client-id
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 redirectURIs:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – https:\/\/172.17.13.10:31234\/callback
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 secret: 089db7e23b19cb628ba841b17cc32ea4
\n<\/em><\/span>\u00a0\u00a0\u00a0 connectors:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – type: ldap
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: ldap
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name: LDAP
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0config:
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 host: ad-server.cpod-velocity.az-fkd.cloud-garage.net:636
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 insecureSkipVerify: false
\nbindDN: cn=administrator,cn=Users,dc=velocity,dc=local
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 bindPW: $BIND_PW_ENV_VAR
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 usernamePrompt: LDAP Username
\n<\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/em>rootCAData:
\nLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdQekNDQkNlZ0F3SUJBZ0lVU2tQd0JPazVYRVFLRlpydXdwZXBoeTlINndzd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2dhNHhDek
\nKQmdOVkJBWVRBa1pTTVF3d0NnWURWUVFJREFOSlJFWXhEakFNQmdOVkJBY01CVkJoY21segpNUlF3RWdZRFZRUUtEQXRNYjJWcGJDMWtkUzFUUlRFTE1Ba0dBMVVFQ3d3Q1UwVXhPRE
\nEyQmdOVkJBTU1MMkZrCkxYTmxjblpsY2k1amNHOWtMWFpsYkc5amFYUjVMbUY2TFdaclpDNWpiRzkxWkMxbllYSmhaMlV1Ym1WME1TUXcKSWdZSktvWklodmNOQVFrQkZoVm1ZbVZ1Y
\n21WcVpHRnNRSFp0ZDJGeVpTNWpiMjB3SGhjTk1qRXdOekEzTURjeQpNekl5V2hjTk16RXdOekExTURjeU16SXlXakNCcmpFTE1Ba0dBMVVFQmhNQ1JsSXhEREFLQmdOVkJBZ01BMGxFClJqRU9NQXdHQTFVRUJ3d0ZVR0Z5YVhNeEZEQVNCZ05WQkFvTUMweHZaV2xzTFdSMUxWTkZNUXN3Q1FZRFZRUUwKREFKVFJURTRNRFlHQTFVRUF3d3ZZV1F0YzJWeWRtVnlMbU53YjJ
\nRdGRtVnNiMk5wZEhrdVlYb3RabXRrTG1OcwpiM1ZrTFdkaGNtRm5aUzV1WlhReEpEQWlCZ2txaGtpRzl3MEJDUUVXRldaaVpXNXlaV3BrWVd4QWRtMTNZWEpsCkxtTnZiVENDQWlJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dJUEFEQ0NBZ29DZ2dJQkFMaWx0WE81WkxNOFRzZ0YKMXFxRFFURi9xV1EzTGkvalU2ZFJqM1VMLys2YitRL0VUVjdIb2VLMi9hK09UdHlRbzY4c
\nk9ySTVJRjNNWlJqKwpzU0JuWC9SejczczYvVjArWXhJTFozSmNNenlWUzZtR1ZhNTZBTmFZRFRqSkErUzF5enZJczFpZXdMWDR2YlFzCnJRdFE2NVphb3NYbFlMSWpxdzZCY01TZUlX
\nNUlUWitlUVF3emlkN2t5ZFBYNDdTBSSm1vR\u2026..1
\n<\/span><\/em><\/span>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2026.<\/span><\/em><\/span><\/p>\n

Relancer le pod dex<\/em> <\/span>dans le namespace tanzu-system-auth <\/em><\/span>pour qu\u2019il prenne en compte la modification.<\/span><\/p>\n

 <\/p>\n

Une fois le cluster de management avec le bon certificat<\/span><\/p>\n

A partir de l\u00e0, cr\u00e9er un cluster de workload :
\n<\/span><\/p>\n

$ tanzu cluster create my-cluster -f <fichier-environnement><\/em><\/span><\/p>\n

Importer le Kubeconfig d\u2019administration du cluster de workload cr\u00e9\u00e9\u00a0:<\/span><\/p>\n

$ tanzu cluster kubeconfig get my-cluster –admin
\n<\/em><\/span>(il y a deux tirets avant l’argument admin mais WordPress n’en n’affiche qu’un seul)<\/em><\/span><\/p>\n

Se connecter au cluster de workload avec le context admin, en tant qu’admin pas besoin de compte :<\/p>\n

$ kubectl use-context my-cluster-admin<\/strong>@my-cluster<\/em><\/span><\/p>\n

Cr\u00e9er un cluster r\u00f4le binding avec le r\u00f4le qui vous int\u00e9resse (ici cluster-admin) pour les utilisateurs souhait\u00e9s, \u00e7a permettra \u00e0 l’utilisateur d’utiliser ce cluster une fois authentifi\u00e9 :
\n<\/span><\/p>\n

$ kubectl create clusterrolebinding admin-fbenrejdal\u00a0 –clusterrole cluster-admin –user fbe@velocity.local
\n(il y a deux tirets avant les arguments clusterrole et user mais WordPress n’en n’affiche qu’un seul)
\n<\/em><\/span><\/p>\n

Exporter le kubeconfig du cluster de workload, c’est ce kubeconfig qu’il faudra transmettre aux utilisateurs, il n’a pas de context admin et demandera \u00e0 l’utilisateur une authentification. L’utilisateur consommera ce cluster en fonction des droits d\u00e9finis dans clusterrolebinding<\/span> <\/em>de l’\u00e9tape pr\u00e9c\u00e9dente :
\n<\/span><\/p>\n

$ tanzu cluster kubeconfig get my-cluster –export-file my-cluster-kubeconfig
\n<\/em><\/span>(il y a deux tirets avant l’argument export mais WordPress n’en n’affiche qu’un seul)<\/em><\/span><\/p>\n

Lancez une commande kubernetes avec le <\/span>fichier kubeconfig g\u00e9n\u00e9r\u00e9, ce qui lancera le navigateur pour permettre l’authtentification :
\n<\/span><\/p>\n

$ kubectl get pods -A –kubeconfig my-cluster-kubeconfig
\n(il y a deux tirets avant l’argument kubeconfig mais WordPress n’en n’affiche qu’un seul)
\n<\/em><\/span><\/p>\n

Vous devriez \u00eatre redirig\u00e9 vers un navigateur avec une page web vous demandant votre nom d\u2019utilisateur et votre mot de passe :
\n<\/span><\/p>\n

\"\"<\/p>\n

Une fois saisies, vous obtiendrez le r\u00e9sultat de votre derni\u00e8re commande :
\n<\/span><\/p>\n

\"\"<\/p>\n

Le r\u00e9sultat de la commande pr\u00e9c\u00e9demment pass\u00e9e devrait s’afficher :
\n<\/span><\/p>\n


\n<\/span>NAMESPACE NAME READY STATUS RESTARTS AGE<\/span>
\nkube-system antrea-agent-q9xpg 2\/2 Running 0 7d15h<\/span>
\nkube-system antrea-agent-qlmj8 2\/2 Running 0 7d15h<\/span>
\nkube-system antrea-controller-6bb57bd84-6cj58 1\/1 Running 0 7d15h<\/span>
\nkube-system coredns-68d49685bd-bjcps 1\/1 Running 0 7d15h<\/span>
\nkube-system coredns-68d49685bd-vttdw 1\/1 Running 0 7d15h<\/span>
\nkube-system etcd-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-apiserver-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-controller-manager-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-proxy-dntrc 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-proxy-k5m9g 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-scheduler-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span>
\nkube-system kube-vip-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span>
\nkube-system metrics-server-66cb4fb659-xlprc 1\/1 Running 0 7d15h<\/span>
\nkube-system vsphere-cloud-controller-manager-vmfwl 1\/1 Running 1 7d15h<\/span>
\nkube-system vsphere-csi-controller-bd8b6cc8c-8ljl8 6\/6 Running 0 7d15h<\/span>
\nkube-system vsphere-csi-node-6xqf5 3\/3 Running 0 7d15h<\/span>
\nkube-system vsphere-csi-node-vmbmq 3\/3 Running 0 7d15h<\/span>
\npinniped-concierge pinniped-concierge-dcd587f97-lk9n5 1\/1 Running 0 7d15h<\/span>
\npinniped-concierge pinniped-concierge-dcd587f97-zrnb7 1\/1 Running 0 7d15h<\/span>
\npinniped-concierge pinniped-concierge-kube-cert-agent-8a8e3e38 1\/1 Running 0 7d15h<\/span>
\npinniped-supervisor pinniped-post-deploy-job-4ldt7 0\/1 Completed 0 7d15h<\/span>
\npinniped-supervisor pinniped-post-deploy-job-m74gz 0\/1 Error 0 7d15h<\/span>
\ntkg-system kapp-controller-69c4d4bbb4-kwk5l 1\/1 Running 0 7d15h<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Afin de simplifier l\u2019authentification des clusters Kubernetes fonctionnant sur diff\u00e9rents clouds, VMware a d\u00e9velopp\u00e9 le projet Pinniped accessible en Opensource. Pinniped a \u00e9t\u00e9 int\u00e9gr\u00e9 par d\u00e9faut dans l\u2019offre VMware Tanzu Kubernetes Grid (TKG) depuis la version 1.3 \u00a0en remplacement de l\u2019extension Gangway. Pinniped permet l’authentification \u00e0 partir de sources OIDC ou LDAP. Dans le cas<\/p><\/div>\n

Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[147],"tags":[548,177,536,538,468,28,540,542,534,544,546,178],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1109"}],"collection":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1109"}],"version-history":[{"count":13,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1109\/revisions"}],"predecessor-version":[{"id":1132,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1109\/revisions\/1132"}],"wp:attachment":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}