Cómo utilizar el servicio Secrets Manager para guardar las claves privadas de SSH

Para guardar la clave privada en el servicio Secrets Manager como un secreto en modo texto sin formato, sigue estos pasos

Supongamos que la clave privada es la siguiente:

$ cat test-ssh-keymanager.pem
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtz
c2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6Vq4XQQnIZ97FmevtUgAA
AIjWYCtU1mArVAAAAAtzc2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6
Vq4XQQnIZ97FmevtUgAAAEAwUQIBATAFBgMrZXAEIgQgJRY8kmxcE/QPgCTmOxdp
RDWlD9jRwRaD2DmEVoLatDB6RvpWrhdBCchn3sWZ6+1SAAAAAAECAwQF
-----END OPENSSH PRIVATE KEY-----

Y lo hemos guardado en un secreto llamado "keyssh". Con el siguiente comando, podemos recuperar su valor y mostrarlo en pantalla:

$ aws secretsmanager get-secret-value --secret-id keyssh \
--region eu-west-1 | jq --raw-output '.SecretString'
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtz
c2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6Vq4XQQnIZ97FmevtUgAA
AIjWYCtU1mArVAAAAAtzc2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6
Vq4XQQnIZ97FmevtUgAAAEAwUQIBATAFBgMrZXAEIgQgJRY8kmxcE/QPgCTmOxdp
RDWlD9jRwRaD2DmEVoLatDB6RvpWrhdBCchn3sWZ6+1SAAAAAAECAwQF
-----END OPENSSH PRIVATE KEY-----

Si ejecutamos lo siguiente, recuperamos el valor y lo guardamos en una variable de entorno:

$ secret_key=$(aws secretsmanager get-secret-value --secret-id keyssh \
--region eu-west-1 | jq --raw-output '.SecretString')

Luego, podemos agregarla al agente de SSH (si no está activo, ejecutamos 'eval $(ssh-agent)'), donde $secret_key es la variable de entorno donde hemos guardado la clave:

$ ssh-add - <<< ${secret_key}

Listamos las claves para comprobar:

$ ssh-add -l

Y finalmente, podemos hacer SSH al servidor. El SSH se encargará de leer la clave desde el ssh-agent:

$ ssh ec2-user@A.BB.CCC.DDDD

Cluster de Kubernetes de andar por casa

Uno de los problemas que he visto que voy a tener con mi cluster de kubernetes que tengo formado por tres maquinas virtuales (un master mas dos nodos worker) es el almacenamiento persistente. Si desplegaba algún contenedor de tipo statefulset, tenia el problema de que los datos del mismo eran solo accesibles si el pod corría en el nodo donde se creo por primera vez, ya otro nodo no podrá acceder al almacenamiento del primer nodo.

Pensando sobre ello y no buscando complicarme la vida en exceso, la solución viene dada por levantar otra maquina virtual que ofrezca el servicio NFS y que los nodos del cluster de kubernetes monten ese recurso NFS. En el cluster de kubernetes hay que desplegar un PVC para que utilice el recurso NFS compartido. De esa forma, todos los nodos del cluster podrán ver los PV que se creen.

Para el despliegue de las maquinas virtuales he utilizado terraform para la creación de las mismas sobre KVM (libvirt).

Para desplegar el software de kubernetes en los nodos y posterior configuración del cluster he utilizado Installing your Kubernetes homelab cluster in minutes with Ansible de Mark Perdue con alguna modificación/corrección.

Para el PVC, lo mejor que he visto ha sido Kubernetes : NFS and Dynamic NFS provisioning de Ccaplat. Aún no lo he probado, será el siguiente paso.

Navegando por Kubernetes

Siempre que me he tenido que mover por kubernetes lo he hecho basandome en pequeñas guias que realizan el despliegue del recurso. Poquito a poco fui viendo las opciones de los deployment, statefulset, daemonset y todo lo que en ese momento necesitaba. Sobre la marcha.

La sensación cuando tengo que modificar algun yaml para desplegar el recurso es de ir un poco a ciegas. ¿Es correcta esta opcion? Ni idea, probemos y ya nos dira kubernetes si es correcta o no cuando se aplique.

Para mi no era lo ideal. Basicamente lo que he llamado, aprender a las bravas. Aunque acudir a la ayuda de kubernetes.io puede aportar claridad, no conseguia quedarme contento. Por eso hay varios comandos de kubectl que si que pueden hacerlo sin salirte de shell.

El primero es kubectl api-versions que te lista todos los recursos de la api. Luego con kubectl explain y la opción --recursive se puede obtener el listado con sus indentaciones de la definición del recurso (los items/nodes). Y si hacemos kubectl explain resource.<item>.<otro-item> podemos ir viendo las definiciones y explicaciones de lo que hacen los parametros de la definición del recurso.

Con eso ya me he quedado más contento. Sé en que me punto me encuentro en lo que respecta a la sintaxis de un yaml de kubernetes cuando tengo que hacer alguna modificación en alguna parte en la que no estoy familiarizado.

Un ejemplo aplicado a los pvc:

kubectl explain persistentvolumeclaims
kubectl explain persistentvolumeclaims --recursive
kubectl explain persistentvolumeclaims.spec --recursive
kubectl explain persistentvolumeclaims.spec.resources.requests