proyectosacc-mirror/docs/04-usuarios-y-permisos.md

04 - Usuarios y Permisos

Quién puede hacer qué en el servidor de proyectosacc.

---

1. Usuarios del sistema

En el servidor EC2 de proyectosacc existen tres usuarios principales. Cada uno tiene un trabajo específico y no se mezclan los roles.

---

👤 ubuntu

Este es el usuario administrador por defecto de Ubuntu en AWS.

¿Qué puede hacer?

• Todo. Es el usuario con permisos de sudo (superusuario).
• Se usa para configurar el servidor por primera vez.
• Puede instalar programas, crear otros usuarios y revisar logs del sistema.

¿Cuándo se usa?

• Durante el setup inicial del servidor.
• Para tareas de mantenimiento que requieren privilegios elevados.
• No se usa para despliegues automáticos ni para ejecutar la aplicación.

---

👤 thoth

Este es el usuario de CI/CD (Integración Continua / Despliegue Continuo).

¿Qué puede hacer?

• ✅ Descargar actualizaciones de los repositorios de código (solo lectura).
• ✅ Subir el frontend compilado al bucket S3 (aws s3 sync).
• ✅ Mover archivos compilados de la API (binarios, JARs, etc.) a los directorios correctos en la EC2.
• ✅ Hacer copias de seguridad (backups) de los binarios antes de actualizarlos.
• ✅ Ejecutar los scripts de despliegue de la API.

¿Qué NO puede hacer?

• ❌ Ejecutar la aplicación final en producción. Ese trabajo es de osiris.

¿Por qué existe?

Para que el pipeline de Bitbucket se conecte por SSH al servidor y haga el despliegue sin necesidad de usar el usuario administrador.

---

👤 osiris

Este es el usuario de ejecución de la aplicación.

¿Qué puede hacer?

• ✅ Iniciar y detener la aplicación SACC.
• ✅ Ejecutar los binarios finales (por ejemplo, archivos .jar de Java).
• ✅ Escribir logs en los directorios asignados.

¿Qué NO puede hacer?

• ❌ Realizar despliegues.
• ❌ Mover archivos de instalación.
• ❌ Acceder a repositorios de código.

¿Por qué existe?

Por seguridad. Si alguien compromete la aplicación, el atacante solo tendría los permisos de osiris, que son muy limitados.

---

2. Separación de privilegios

Este modelo se llama SoD (Segregation of Duties) o "Separación de Funciones".

La idea es simple: una sola persona (o usuario) no debe poder hacer todo.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   thoth     │      │   osiris    │      │   ubuntu    │
│  (CI/CD)    │      │ (ejecución) │      │  (admin)    │
│             │      │             │      │             │
│ Despliega   │ ──▶  │ Ejecuta     │ ◀──  │ Administra  │
│ la app      │      │ la app      │      │ el server   │
└─────────────┘      └─────────────┘      └─────────────┘

---

3. Llaves SSH

Las llaves SSH son como un "carnet de identidad digital" que permite conectarse al servidor sin escribir una contraseña cada vez. En proyectosacc usamos un par de llaves SSH dedicado, generado específicamente para este proyecto. No se usa contraseña ni herramientas como sshpass.

¿Cómo funcionan?

Una llave SSH siempre viene en par:

1. Llave privada: es secreta. Solo la tiene quien se va a conectar.
2. Llave pública: se puede compartir. Se coloca en el servidor para decirle "confía en quien tenga la llave privada que corresponde a esta pública".

Analogía simple

Imagina un candado con dos llaves:

• La pública es el candado mismo. Lo pones en la puerta del servidor.
• La privada es la llave que abre el candado. Solo tú la tienes.

---

4. Dónde viven las llaves

Llave privada

• Vive en: las variables seguras de Bitbucket Pipelines.
• Nombre de variable: PROYECTOSACC_SSH_KEY
• Formato: codificada en base64 (esto evita que Bitbucket modifique el formato).
• Quién la usa: el pipeline de Bitbucket cuando se conecta por SSH al servidor.

Llave pública

• Vive en: el archivo ~/.ssh/authorized_keys del usuario thoth en la EC2.
• Ruta completa: /home/thoth/.ssh/authorized_keys
• Función: permite que el pipeline se conecte sin contraseña.

Llaves del servidor hacia Bitbucket

• El usuario thoth también tiene sus propias llaves SSH para clonar repositorios desde Bitbucket.
• Ubicación: /home/thoth/.ssh/
• Ejemplo de nombre: proyectosacc_server_thoth_develop_TO_bitbucket_pipeline_ci_cd

---

5. Resumen rápido

Usuario	Rol principal	Llave SSH asociada
ubuntu	Administrador del servidor	Llave de acceso inicial a la EC2 (creada al lanzarla en AWS)
thoth	Despliegue automático (CI/CD)	PROYECTOSACC_SSH_KEY en Bitbucket Variables
osiris	Ejecutar la aplicación	No necesita llave SSH para conexiones externas

---

Anterior: 03-infraestructura-aws.md
Siguiente: 05-pipeline-bitbucket.md