Consejos para guardar credenciales

B

.

Chorlo

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

1 1 respuesta
wdaoajw

Si vas a usarlo tú solo, no te calientes la cabeza. Mantienes el .pem por tu pc por ahí y si lo pierdes te generas otro.

Gestionar todo esto es un coñazo como te dice #2

1
D

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.

1 respuesta
B

.

1 respuesta
D

#5 Autenticación por clave. Metemos las ssh public de cada usuario dentro de

/home/<usuario>/.ssh/authorized_keys

De esta forma necesitan su clave privada para acceder y no hay que introducir passwords.

1 respuesta
B

.

D

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.

1 respuesta
NeV3rKilL

Las credenciales que se necesitan en código se suelen grabar en archivos rollo dotenv y luego se importan.

B

.

1 respuesta
D

#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

1 respuesta
B

.

1 respuesta
D

#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)

Usuarios habituales