Skip to main content

Gobierno de Repositorios y Buenas Prácticas

13. Gobierno de Repositorios (Estándares Corporativos)​

Para mantener el orden a escala empresarial, todos los repositorios creados bajo la organización alpura-enterprise deben cumplir rigurosamente con los siguientes estándares de gobernanza:

Convención de Nomenclatura (Naming Conventions)​

  • Repositorios de Microservicios Backend: msa-[dominio]-[nombre-servicio]-backend (Ej: msa-sales-payment-backend).
  • Repositorios de Aplicaciones Frontend: app-[canal]-[nombre-portal] (Ej: app-portal-distribuidor).
  • Repositorios de Infraestructura: infra-[proveedor/tecnología]-[proposito] (Ej: infra-gcp-gke-clusters).

Estructura Interna del Repositorio de GitOps (msa-infra-gitops)​

msa-infra-gitops/
├── apps/                        # Definiciones de Aplicaciones de Argo CD
│   └── msa-sales-backend/
│       ├── base/                # Recursos base comunes (Deployments, Services)
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/            # Configuraciones específicas por ambiente
│           ├── dev/
│           │   ├── kustomization.yaml
│           │   └── values.yaml
│           ├── uat/
│           │   ├── kustomization.yaml
│           │   └── values.yaml
│           └── prod/
│               ├── kustomization.yaml
│               └── values.yaml
├── bootstrap/                   # Inicialización del clúster (App of Apps pattern)
│   ├── root-application.yaml
│   └── system-components/
└── infrastructure/              # Manifiestos globales de infraestructura K8s
    ├── namespaces.yaml
    └── network-policies.yaml

14. Buenas Prácticas Generales (50 Reglas de Oro)​

A continuación, se listan de forma obligatoria las 50 reglas que rigen la operación de la plataforma:

GitHub (1 - 10)​

  1. Prohibir force pushes (git push -f) en todas las ramas protegidas de manera permanente.
  2. Requerir firma criptográfica GPG obligatoria para todos los commits de desarrollo.
  3. El archivo CODEOWNERS debe estar configurado y bloqueado en la raíz de cada repositorio.
  4. Las ramas de features deben destruirse automáticamente inmediatamente después de realizar el Merge.
  5. Todos los Pull Requests deben requerir un mínimo de dos aprobaciones de revisores distintos antes de permitir el Merge.
  6. Habilitar la auditoría en tiempo real mediante webhooks enviados a herramientas SIEM corporativas.
  7. Las claves SSH de despliegue individuales deben rotarse de manera automatizada de forma trimestral.
  8. Bloquear mediante reglas de expresiones regulares el commit accidental de cualquier tipo de secreto o contraseña.
  9. Mantener las descripciones de los commits alineadas estrictamente al formato Conventional Commits (ej: feat(api): ...).
  10. Ejecutar dependabot de manera diaria para la actualización automatizada de dependencias vulnerables.

Jenkins (11 - 20)​

  1. Los pipelines deben ser estrictamente declarativos y almacenados en un archivo Jenkinsfile controlado por versión.
  2. La ejecución de pipelines debe ocurrir en agentes efímeros desplegados dinámicamente como Pods dentro del clúster.
  3. Establecer límites de recursos de CPU y Memoria estrictos para todos los agentes de Jenkins en Kubernetes.
  4. Las dependencias externas (Maven, NPM) deben recuperarse exclusivamente a través de la caché interna del proxy de Nexus.
  5. Configurar alertas push inmediatas a Slack/Teams para reportar la caída o el fallo crítico de cualquier pipeline.
  6. Ninguna contraseña o secreto debe estar en texto plano en el pipeline; utilizar únicamente integraciones seguras con credenciales de Jenkins o Vault.
  7. Limitar el historial de ejecuciones a un máximo de 30 días para evitar el consumo innecesario de almacenamiento del servidor maestro.
  8. Utilizar librerías compartidas de Jenkins (Shared Libraries) para centralizar pasos comunes de empaquetado y escaneo.
  9. El paso de análisis estático con SonarQube debe tener habilitado el bloqueo automático (abortPipeline: true) si el Quality Gate no se supera.
  10. Los agentes de ejecución de Jenkins deben operar con cuentas de servicio de Kubernetes restringidas (Mínimo Privilegio).

Argo CD (21 - 30)​

  1. Utilizar el patrón App of Apps para el arranque y configuración global de nuevos clústeres.
  2. Configurar la política de eliminación de recursos (Prune) para asegurar la limpieza automática de Pods y servicios borrados en Git.
  3. Desactivar el auto-sync automático de Argo CD en el entorno de producción para requerir una intervención manual controlada.
  4. Habilitar la corrección automática (Self-Heal) en DEV y UAT para revertir de manera inmediata cualquier cambio manual realizado por administradores en el clúster.
  5. El acceso de usuario a la UI de Argo CD debe realizarse de forma obligatoria mediante SSO (Single Sign-On) integrado con el proveedor de identidad corporativo.
  6. Mapear permisos de solo lectura para los desarrolladores de backend y frontend en la interfaz visual de Argo CD.
  7. Monitorear activamente el desfase de configuraciones (Configuration Drift) emitiendo alarmas al equipo de operaciones.
  8. Segmentar las aplicaciones de Argo CD en proyectos lógicos segregados para evitar colisiones accidentales de configuraciones.
  9. Las credenciales de acceso a los repositorios de GitOps almacenadas en Argo CD deben usar tokens de aplicación con permisos reducidos.
  10. Configurar exclusiones de sincronización para recursos volátiles de Kubernetes como HorizontalPodAutoscalers (HPA).

Kubernetes & Helm (31 - 40)​

  1. Todas las cargas de trabajo deben tener definidos obligatoriamente límites y requerimientos de recursos (Limits y Requests).
  2. Configurar de forma mandatoria pruebas de vida y disponibilidad (Liveness y Readiness Probes) en todos los servicios expuestos.
  3. Está estrictamente prohibido usar la etiqueta de imagen de contenedor :latest en cualquier entorno.
  4. Utilizar Pod Disruption Budgets (PDB) en ambientes productivos para garantizar la alta disponibilidad durante eventos de mantenimiento del clúster.
  5. Bloquear la ejecución de contenedores que requieran acceso privilegiado o privilegios de súper usuario de Linux (runAsNonRoot: true).
  6. Configurar políticas de red (Network Policies) restrictivas por defecto para impedir la comunicación lateral no autorizada entre namespaces.
  7. No almacenar configuraciones estáticas dentro de la imagen de contenedor; inyectarlas en tiempo de ejecución mediante ConfigMaps.
  8. Utilizar Helm charts globales compartidos como bibliotecas de plantillas base en lugar de duplicar manifiestos YAML de Kubernetes.
  9. Ejecutar herramientas de linting de manifiestos y charts de Helm durante el paso de pruebas en el pipeline de CI.
  10. Asegurar que las imágenes de contenedores sean inmutables utilizando referencias de tags de versionamiento únicas.

WSO2 (41 - 50)​

  1. Declarar las definiciones de APIs utilizando estrictamente el enfoque API-as-Code integrado en el pipeline de CI/CD.
  2. Habilitar de manera mandatoria políticas de limitación de tasa (Rate Limiting) en todos los endpoints expuestos públicamente.
  3. Utilizar certificados SSL/TLS vigentes firmados por una entidad certificadora de confianza para el acceso al API Gateway.
  4. Integrar la validación y verificación de tokens de seguridad (OAuth2/JWT) a nivel del API Gateway para aliviar la carga del backend.
  5. Sincronizar de forma automatizada las definiciones técnicas expuestas en el portal de desarrolladores con las especificaciones de OpenAPI de Git.
  6. Monitorear los tiempos de respuesta y latencia de las transacciones del Gateway exportando métricas hacia Prometheus y Grafana.
  7. Desplegar los componentes de WSO2 en esquemas de Alta Disponibilidad distribuidos en múltiples zonas de disponibilidad física.
  8. Proteger la publicación de APIs en el Developer Portal exigiendo roles y flujos de aprobación de negocio del Product Owner.
  9. Versionar de forma estricta los endpoints de APIs expuestos para garantizar la compatibilidad con clientes legados (ej: /v1, /v2).
  10. Implementar auditorías periódicas automatizadas sobre los logs de consumo de APIs para la prevención y detección de anomalías de seguridad.