Initial commit: Terraform infrastructure, pipelines, docs and scripts
This commit is contained in:
Evert Daniel Romero Garrido
@@ -0,0 +1,134 @@
|
||||
# 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)*
|
||||
Reference in New Issue
Block a user