# 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` | `` | | `AWS_SECRET_ACCESS_KEY` | `` | 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*