.
Cada uno tiene su propio pem y usuario. Sólo los necesarios tienen capacidad de sudo. La mayoría no tiene acceso, es Jenkins o cualquier otro software el que ejecuta las distintas tareas de despliegue en los mismos. Cada máquina tiene una configuración con el listado de usuarios. No creo que sea el mejor modo la verdad, pero tampoco hemos encontrado nada mejor :-S
En nuestro caso, guardamos el contenido de los .pem en 1Password.
Pero los guardamos como último recurso. Luego cada instancia tiene configurado el acceso a los usuarios que han de tener acceso para acceder de forma nominal.
De hecho, sólo hacemos login a veces para pasar el configuration manager (saltstack, ansible, puppet, etc..) y este cree todos los usuarios y aplique configuraciones que necesitamos.
#5 Autenticación por clave. Metemos las ssh public de cada usuario dentro de
/home/<usuario>/.ssh/authorized_keysDe esta forma necesitan su clave privada para acceder y no hay que introducir passwords.
El .pem de Amazon lo vas a crear siempre, de hecho creo que te obliga. Luego ya cada uno gestiona como acceder a dicha instancia.
Las credenciales que se necesitan en código se suelen grabar en archivos rollo dotenv y luego se importan.
#10 Si, pero no me refiero a eso. Me refiero que luego , al crear instancias o un AutoScaling Group, has de escoger un Key Pair, sea creada o importada.
Y no voy a importar mi par de claves SSH ahí para que las use otro xD
#12 Si, al final es meter la public key en el fichero authorized_keys pero en este caso , del usuario que se genera al crear la instancia (ec2-user, ubuntu, etc... dependiendo de la AMI)