# 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`](03-infraestructura-aws.md)*  
*Siguiente: [`05-pipeline-bitbucket.md`](05-pipeline-bitbucket.md)*