Dans notre première partie de cet article, nous avons vu ensemble l’installation d’OpenDistro sur Kubernetes en utilisant des certificats auto-signés que presque personne ne trouve la motivation pour les gérer. Ils trouvent que c’est une tâche répétitive, ennuyeuse et qui demande plus de prudence au fur et à mesure du nombre de certificats utilisés.
Si vous nous partagez le même avis, nous vous conseillons de lire cette deuxième partie de l’article et qui vous permettra de déléguer toute la gestion de ces certificats au cert-manager.
D’ailleurs, si vous n’avez pas encore consulté la première partie de cet article, vous pouvez la trouver sur le lien suivant :
cert-manager est un outil de gestion de certificats sur Kubernetes. Il délivre des certificats à partir de diverses sources telles que Let’s Encrypt, HashiCorp Vault, Venafi, une paire de clés à signature puis les présente en tant que secrets aux applications.
Comment pouvons nous le déployer sur un cluster kubernetes ?!
cert-manager est très simple à déployer, nous avons besoin du helm et suivre les étapes suivantes:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install
cert-manager jetstack/cert-manager
--namespace cert-manager
--create-namespace
--version v1.4.0
--set installCRDs=true
Et voilà comme promis c’est simple à installer un cert-manager sur votre cluster. Maintenant, la prochaine étape consiste à configurer notre Issuer.
Un Issuer est une ressource Kubernetes qui représente des autorités de certification (CA) capables de générer des certificats. Il existe de multiples types d’émetteurs de certificats, les plus importants sont les suivants:
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: selfsigned-issuer
namespace: opendistro
spec:
selfSigned: {}
Les certificats sont également des ressources Kubernetes, cette ressource se base sur un Issuer pour être générée. Une fois créés, le cert- manager va établir des secrets kubernetes pour stocker ces certificats qui seront présentés aux applications par la suite.
Pour générer les certificats pour notre OpenDistro, nous devons passer un manifeste kubernetes avec les options suivantes :
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: es-transport-tls
namespace: opendistro
spec:
isCA: true
duration: 2160h # 90d 2160h
renewBefore: 168h # 7d 168h
commonName: es-client
dnsNames:
- es-client
privateKey:
algorithm: RSA
encoding: PKCS8
size: 4096
issuerRef:
kind: Issuer
name: selfsigned-issuer
secretName: es-transport-tls
Ne vous inquiétez pas, nous allons expliquer par la suite certaines options qui ne sont pas explicites:
commonName: Il doit être identique à la valeur de node_dn dans la configuration d’OpenDistro.
encoding: par défaut cert-manager génère des privatekeys au format PKCS11 qui n’est pas supporté par OpenDistro, donc nous devons le changer en PKCS8.
secretName: le nom du secret Kubernetes où le certificat et la clé privée seront stockés.
Pour OpenDistro la configuration ainsi que le reste de l’installation resteront les mêmes à l’exception de quelques options liées aux noms des certificats.
......
elasticsearch:
......
tls:
existingCertSecret: es-transport-tls
existingCertSecretCertSubPath: tls.crt
existingCertSecretKeySubPath: tls.key
existingCertSecretRootCASubPath: ca.crt
.........
Comme les clés secrètes sont modifiées, nous devons adapter la configuration. Pour le reste de l’installation, elle restera la même.
Une fois la modification est faite, vous pouvez procéder à l’installation :
helm upgrade --install
-n opendistro <release_name> -f values.yaml
/opendistro-build/helm/opendistro-es
à la fin de cet article, j’espère que ce sujet vous a été utile et comme d’habitude, veuillez trouver tous les fichiers de la configuration nécessaires sur mon github.
Merci pour cette lecture et à la prochaine avec un nouveau sujet et des nouvelles astuces.