Evert Daniel Romero Garrido
3fe8cb1391
- Use DEV_S3_ARTIFACTS_BUCKET and PROD_S3_ARTIFACTS_BUCKET in 06_install instead of generic S3_ARTIFACTS_BUCKET to prevent cross-env reads - Add terraform/environments/*.tfvars to .gitignore to prevent secret leaks - Update prod backend state bucket name to proyectosacc-specific bucket - Add CI/CD credential policy documentation
234 lines
10 KiB
Markdown
234 lines
10 KiB
Markdown
# 12 - Credenciales AWS para CI/CD de proyectosacc
|
|
|
|
> Guía para configurar credenciales persistentes de AWS en Bitbucket Pipelines, evitando el uso de tokens de sesión SSO que expiran frecuentemente.
|
|
|
|
---
|
|
|
|
## 1. El problema con los tokens de sesión SSO
|
|
|
|
Los **tokens de sesión SSO** (Single Sign-On) son credenciales **temporales** que expiran después de un período corto (generalmente entre 1 y 12 horas).
|
|
|
|
### ¿Por qué no funcionan bien en CI/CD?
|
|
|
|
| Problema | Impacto |
|
|
|----------|---------|
|
|
| **Expiración frecuente** | El pipeline falla inesperadamente cuando el token vence. |
|
|
| **Renovación manual** | Requiere que un usuario humano inicie sesión en SSO y genere nuevos tokens. |
|
|
| **Bloqueo de despliegues** | Un despliegue automatizado en medio de la noche puede fallar por un token vencido. |
|
|
| **No son idóneos para automatización** | Están diseñados para uso interactivo, no para pipelines desatendidos. |
|
|
|
|
**Conclusión**: Para un pipeline CI/CD que debe ejecutarse de forma automática y confiable, se necesitan credenciales **persistentes** o un mecanismo de autenticación **automatizado** como OIDC.
|
|
|
|
---
|
|
|
|
## 2. Alternativas recomendadas
|
|
|
|
### Opción A (Mejor práctica): OIDC con Bitbucket Pipelines
|
|
|
|
Bitbucket Pipelines soporta **OpenID Connect (OIDC)**, que permite que el pipeline asuma un rol de AWS **sin usar credenciales estáticas**.
|
|
|
|
**Ventajas:**
|
|
- No hay access keys que roten manualmente.
|
|
- Cada ejecución del pipeline obtiene credenciales temporales automáticamente.
|
|
- Menor superficie de ataque (no hay secretos almacenados en Bitbucket).
|
|
|
|
**Desventaja:**
|
|
- Requiere configuración inicial más compleja en IAM (OIDC provider, trust policy, rol).
|
|
|
|
Para la configuración completa de OIDC, consulta:
|
|
- [`docs/04-integracion-bitbucket-aws.md`](../docs/04-integracion-bitbucket-aws.md) (sección "Deploy to AWS with OIDC").
|
|
|
|
### Opción B (Inmediata y práctica): IAM User con Access Keys de larga vida
|
|
|
|
Si OIDC no es viable en el corto plazo, la alternativa estándar es crear un **usuario IAM dedicado** con access keys de larga vida, guardadas como variables seguras en Bitbucket.
|
|
|
|
**Usuarios recomendados:**
|
|
- `bitbucket-pipelines-proyectosacc-dev` (cuenta DEV: `668889063715`)
|
|
- `bitbucket-pipelines-proyectosacc-prod` (cuenta PROD: por confirmar)
|
|
|
|
**Principios:**
|
|
- **Un usuario por ambiente**: nunca compartir credenciales entre DEV y PROD.
|
|
- **Solo acceso programático**: sin contraseña de consola AWS.
|
|
- **Mínimo privilegio**: solo los permisos estrictamente necesarios para el pipeline.
|
|
|
|
---
|
|
|
|
## 3. Política IAM mínima requerida para proyectosacc
|
|
|
|
El pipeline de `proyectosacc` realiza las siguientes operaciones en AWS:
|
|
|
|
1. **S3**: Sincroniza el frontend React al bucket de sitio estático.
|
|
2. **S3**: Sube el artefacto `.jar` de la API al bucket de artefactos.
|
|
3. **CloudFront**: Invalida la caché de la distribución tras el despliegue.
|
|
4. *(Futuro)* **Terraform/IaC**: Gestiona EC2, RDS, Route 53, ACM, CloudFormation, etc.
|
|
|
|
A continuación se presenta una política **compuesta** que cubre tanto el despliegue de aplicación actual como la gestión de infraestructura mediante Terraform/CloudFormation.
|
|
|
|
**Archivo de política:** [`iam-policy-ci-cd-proyectosacc.json`](iam-policy-ci-cd-proyectosacc.json)
|
|
|
|
### Resumen de permisos incluidos
|
|
|
|
| Servicio | Permisos | Justificación |
|
|
|----------|----------|---------------|
|
|
| **S3** | `PutObject`, `DeleteObject`, `ListBucket`, `GetObject` | `aws s3 sync` frontend y subida/descarga de artefactos `.jar`. |
|
|
| **CloudFront** | `CreateInvalidation`, `GetInvalidation`, `ListInvalidations` | Invalidar caché tras deploy. |
|
|
| **CloudFront** | `GetDistribution`, `UpdateDistribution`, `CreateDistribution` | Gestión de distribución vía Terraform. |
|
|
| **EC2** | `Describe*`, `RunInstances`, `TerminateInstances`, `CreateTags`, etc. | Gestión de instancias, security groups, EIPs, VPC. |
|
|
| **RDS** | `Describe*`, `CreateDBInstance`, `ModifyDBInstance`, `DeleteDBInstance` | Gestión de base de datos MariaDB. |
|
|
| **Route 53** | `ChangeResourceRecordSets`, `ListHostedZones`, `GetChange` | Gestión de registros DNS. |
|
|
| **ACM** | `RequestCertificate`, `DescribeCertificate`, `DeleteCertificate` | Gestión de certificados SSL. |
|
|
| **IAM** | `Get*`, `List*`, `SimulatePrincipalPolicy` | Validación de permisos y lectura de roles/políticas. |
|
|
| **CloudFormation** | `CreateStack`, `UpdateStack`, `DeleteStack`, `DescribeStacks` | Despliegue de stacks (si aplica). |
|
|
| **CloudWatch Logs** | `CreateLogGroup`, `CreateLogStream`, `PutLogEvents` | Logs de despliegue. |
|
|
|
|
> **Nota**: Si el pipeline **solo** despliega la aplicación (sin tocar infraestructura), puedes reducir la política a los permisos de **S3** y **CloudFront** únicamente. Consulta el archivo JSON para ver las secciones comentadas.
|
|
|
|
---
|
|
|
|
## 4. Buenas prácticas de seguridad
|
|
|
|
### 4.1 Almacenamiento de credenciales
|
|
|
|
- Guarda `AWS_ACCESS_KEY_ID` y `AWS_SECRET_ACCESS_KEY` como variables **Secured** en Bitbucket Pipelines.
|
|
- Nunca escribas credenciales en código, logs ni documentación.
|
|
- Considera migrar a **AWS Secrets Manager** o **Parameter Store** como paso intermedio hacia OIDC.
|
|
|
|
### 4.2 Rotación de credenciales
|
|
|
|
- **Rotar access keys cada 90 días** como máximo.
|
|
- Programa recordatorios en el calendario del equipo.
|
|
- Documenta el proceso de rotación en un runbook accesible.
|
|
|
|
### 4.3 Sin acceso a consola
|
|
|
|
- Los usuarios IAM de CI/CD deben tener **solo acceso programático**.
|
|
- No asignar contraseña de consola ni políticas de MFA obligatorio al usuario (el pipeline no puede usar MFA).
|
|
|
|
### 4.4 Principio de mínimo privilegio
|
|
|
|
- Revisa la política IAM cada vez que el pipeline cambie de operaciones.
|
|
- Usa ARNs específicos en lugar de `*` siempre que sea posible.
|
|
- Considera separar permisos en políticas distintas por servicio.
|
|
|
|
### 4.5 Auditoría
|
|
|
|
- Habilita **AWS CloudTrail** en ambas cuentas (DEV y PROD) para registrar todas las llamadas a la API.
|
|
- Configura alertas en CloudWatch/Security Hub para actividad sospechosa (ej. `CreateAccessKey` fuera de horario).
|
|
|
|
### 4.6 Separación de ambientes
|
|
|
|
| Ambiente | Cuenta AWS | Usuario IAM |
|
|
|----------|------------|-------------|
|
|
| DEV | `668889063715` | `bitbucket-pipelines-proyectosacc-dev` |
|
|
| PROD | `523761210517` o `739086995772` | `bitbucket-pipelines-proyectosacc-prod` |
|
|
|
|
**Nunca reutilices el mismo par de access keys en DEV y PROD.**
|
|
|
|
---
|
|
|
|
## 5. Instrucciones paso a paso para crear el usuario IAM
|
|
|
|
### Paso 1: Crear el usuario IAM (Consola AWS)
|
|
|
|
1. Inicia sesión en la [Consola AWS](https://console.aws.amazon.com/) de la cuenta correspondiente (DEV o PROD).
|
|
2. Navega a **IAM > Users > Add users**.
|
|
3. **User name**: `bitbucket-pipelines-proyectosacc-dev` (o `-prod`).
|
|
4. Selecciona **Access key - Programmatic access**.
|
|
5. **NO** selecciones "Password - AWS Management Console access".
|
|
6. Haz clic en **Next: Permissions**.
|
|
|
|
### Paso 2: Adjuntar la política
|
|
|
|
1. Selecciona **Attach policies directly**.
|
|
2. Haz clic en **Create policy**.
|
|
3. Ve a la pestaña **JSON** y pega el contenido del archivo [`iam-policy-ci-cd-proyectosacc.json`](iam-policy-ci-cd-proyectosacc.json).
|
|
4. Reemplaza los placeholders de ARN (`arn:aws:s3:::ccsoft-proyectosacc-*`, etc.) con los recursos reales de tu cuenta.
|
|
5. Asigna un nombre a la política: `proyectosacc-ci-cd-deployment-policy`.
|
|
6. Guarda la política y adjúntala al usuario.
|
|
|
|
### Paso 3: Obtener las access keys
|
|
|
|
1. Completa la creación del usuario.
|
|
2. En la pantalla de confirmación, copia:
|
|
- **Access key ID**
|
|
- **Secret access key**
|
|
3. **Importante**: Este es el único momento en que verás la secret access key. Guárdala de forma segura (ej. en un password manager).
|
|
|
|
### Paso 4: Configurar en Bitbucket Pipelines
|
|
|
|
1. Ve al repositorio de `proyectosacc` en Bitbucket.
|
|
2. Navega a **Repository settings > Pipelines > Repository variables**.
|
|
3. Agrega las siguientes variables y márcalas como **Secured**:
|
|
|
|
| Variable | Valor |
|
|
|----------|-------|
|
|
| `AWS_ACCESS_KEY_ID` | `<Access key ID del usuario IAM>` |
|
|
| `AWS_SECRET_ACCESS_KEY` | `<Secret access key del usuario IAM>` |
|
|
|
|
4. Verifica que el pipeline `bitbucket-pipelines.yml` ya referencia estas variables en los pasos de `publish` y `deploy`.
|
|
|
|
### Paso 5: Validar el despliegue
|
|
|
|
1. Ejecuta un pipeline de prueba en la rama `developer` (DEV).
|
|
2. Verifica que los pasos `05_publish` y `07_deploy` finalicen exitosamente.
|
|
3. Revisa los logs de CloudTrail para confirmar que las llamadas a la API provienen del usuario IAM esperado.
|
|
|
|
---
|
|
|
|
## 6. Instrucciones vía AWS CLI
|
|
|
|
Si prefieres automatizar la creación con la CLI de AWS:
|
|
|
|
```bash
|
|
# Variables
|
|
USER_NAME="bitbucket-pipelines-proyectosacc-dev"
|
|
POLICY_NAME="proyectosacc-ci-cd-deployment-policy"
|
|
POLICY_DOCUMENT="file://iam-policy-ci-cd-proyectosacc.json"
|
|
|
|
# 1. Crear usuario IAM
|
|
aws iam create-user --user-name "$USER_NAME"
|
|
|
|
# 2. Crear política inline (o managed) y obtener su ARN
|
|
POLICY_ARN=$(aws iam create-policy \
|
|
--policy-name "$POLICY_NAME" \
|
|
--policy-document "$POLICY_DOCUMENT" \
|
|
--query 'Policy.Arn' --output text)
|
|
|
|
# 3. Adjuntar política al usuario
|
|
aws iam attach-user-policy \
|
|
--user-name "$USER_NAME" \
|
|
--policy-arn "$POLICY_ARN"
|
|
|
|
# 4. Crear access keys
|
|
aws iam create-access-key --user-name "$USER_NAME"
|
|
```
|
|
|
|
> **Nota de seguridad**: El comando `create-access-key` devuelve la `SecretAccessKey` en texto plano. Captúrala de forma segura y no la almacenes en el historial de comandos de tu terminal.
|
|
|
|
---
|
|
|
|
## 7. Recomendación final
|
|
|
|
Aunque los **IAM users con access keys** resuelven el problema inmediato de la expiración de credenciales SSO, la solución **ideal** a mediano plazo para `proyectosacc` es migrar a **OIDC**.
|
|
|
|
### Hoja de ruta sugerida
|
|
|
|
| Fase | Acción | Prioridad |
|
|
|------|--------|-----------|
|
|
| **Inmediata** | Crear usuarios IAM con access keys y reemplazar los tokens SSO en Bitbucket. | Alta |
|
|
| **Corto plazo** | Implementar rotación automática de access keys (cada 90 días). | Media |
|
|
| **Mediano plazo** | Migrar a OIDC para eliminar credenciales estáticas completamente. | Media/Alta |
|
|
|
|
---
|
|
|
|
## Referencias
|
|
|
|
- [`docs/08-seguridad-buenas-practicas.md`](../docs/08-seguridad-buenas-practicas.md) — Seguridad general de CI/CD en CCsoft.
|
|
- [`docs/04-integracion-bitbucket-aws.md`](../docs/04-integracion-bitbucket-aws.md) — Integración de Bitbucket con AWS (incluye OIDC).
|
|
- [`05-pipeline-bitbucket.md`](05-pipeline-bitbucket.md) — Funcionamiento del pipeline de `proyectosacc`.
|
|
- [`08-seguridad-y-secretos.md`](08-seguridad-y-secretos.md) — Gestión de secrets en `proyectosacc`.
|
|
|
|
---
|
|
|
|
*Área de Tecnología y Desarrollo — CCsoft — Abril 2026*
|