EC2 KeyPair As Terraform External Data Source

[Jean-Baptiste-Lasselle]

Problème inital

La création de la paire de clef SSH sur AWS EC2, avec Terraform, est particulièrement chiante :

• Terraform nous propose de nous débrouiller pour générer une paire de clefs,
• et de fournir la valeur de la clef publique, pour l'envoyer à AWS EC2 et enregistrer la clef voulue (au leiu de laisser AWS générer une paire de clefs).
• Terraform a raison de proposer ce modèle : il permet de centrailiser la totalité de la gestion des clefs SSH dans uen solution qui est laissée au choix de l'uitilisateur de Terraform.

Très bien, le seul problème est que le format de paires de clef AWS EC2 est particulièrement chiant : par exemple uen clef générée classiquement avec openssh et une commande de la forme ssh-keygen ..., donnera une clef qu' AWS se fera un plaisir de rejeter.

Il est clair que la solution définitive DOIT être :

• de savoir générer correctement cette paire de clefs, dans le format attendu. Probabalement qu'HashiCorp Vault peut proposer une solution ici.
• et intégrér le tout avec une solution de gestion de clefs : en l'occurence je vais choisir HAshiCOrp Vault.

Tâche

En lieu et place du ./wait-for-ec2-keypair.sh, et du conteneur opérateur AWS CLI, implémenter une Terraform External Data Source, dont la responsabilité sera :

• de lancer la requête aws cli, pour exécuter la génération de la AWS EC2 KeyPair
• et de récupérer la clef privée retouréne dans leJSon, pour persister la clef privée .... où?
• Oh mais il faudrait que ce soit directement perissté dans HashiCorp Vault, au lieu de persister dans le contexte local d'exécution de terraform. C'est importnat pour permettre de rendre très agile l'exécution terraform : on s'en fout de ce qu'il y localement à l'exécution, on sait que c'est le terraform state que TOUT repose (il n'ya pas pas besoin de "faire attention" se souvenir de détail comme ah oui voilà le nom de fichier dans lequel je persiste ma clef, ... Oh mais non, mais SURTOUT : la clef privée est un secret Ô combien secret, et il n'est pas question de l'embarquer dans un git commit de l'Etat Terraform

(tiens marrant est-ce qu'on pourrait implémenter une machien de turing en détournanat terraform, et en se servant du terraform state versionné dans un repo git, et se servir du repo git comme du ruban de turing ? )

Sécurité

Quant à la sécurité , quelque soit la solution, toute invocation de AWS doit être sécurisée à l'aide du https://learn.hashicorp.com/vault/identity-access-management/vault-agent-aws

Intérêt

• se débarasser d'un conteneur
• re-centraliser la totalité de l'orchestration de teraformation dans la recette terraform, pour rester dans un contexte de pure Infrastructure as code : le conteneur à côté est un sparadrap

[Jean-Baptiste-Lasselle]

https://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html

[Jean-Baptiste-Lasselle]

Misc problems with EC2 generated keys

jbl@poste-devops-typique:~/a-k8s-demo$ docker exec -it awscli_bee bash
beeio@724241985b7b:/aws/playground$ openssl rsa -in ~/creshAWSSSHkey -out ~/creshAWSSSHkey.nopass.key
unable to load Private Key
140102148460608:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: ANY PRIVATE KEY
beeio@724241985b7b:/aws/playground$