Separa la automatización de la administración personal
Un pipeline de API de informes necesita seleccionar un artefacto aprobado e invocar una acción de versión controlada. Eso no requiere automáticamente crear usuarios, cambiar la facturación o leer todos los secretos de la aplicación. Empieza con un inventario de permisos y un entorno de prueba protegido; mantén las credenciales fuera de documentos, repositorios y registros de ejemplo.
El acceso humano a la recuperación debe permanecer separado para que revocar una credencial de despliegue no elimine la única vía de investigación. Identifica un mantenedor autorizado y una verificación de host independiente. Una segunda clave sin restricciones es otra credencial, no un rol más acotado.
Describe la operación permitida con precisión
| Capacidad | ¿Necesaria? | Límite |
|---|---|---|
| Leer artefacto aprobado | Sí | Repositorio/versión concreta |
| Invocar acción de versión | Sí | App y entorno fijos |
| Leer todos los secretos de runtime | Evitar | Identidad de runtime controlada |
| Modificar usuarios o política de SSH | No | Administración separada |
| Cambiar la configuración del flujo de trabajo | No para la identidad de runtime | Revisión de repositorio protegido |
| Eliminar copias de seguridad | No | Permisos de recuperación separados |
Valida las entradas de la acción de versión. Un comando restringido que concatena texto arbitrario en un shell privilegiado sigue permitiendo trabajo no deseado. Revisa juntos el comportamiento del wrapper, las rutas escribibles y la confianza en el artefacto. Privilegios amplios de sudo o acceso al socket de Docker pueden anular el límite previsto.
Trata las ediciones de flujos de trabajo como acceso a credenciales
Alguien capaz de cambiar pasos de flujo de trabajo de confianza puede usar o exponer sus credenciales. Revisa los permisos del repositorio, los entornos de despliegue protegidos y qué eventos ejecutan trabajos privilegiados. Mantén las credenciales de producción lejos del código de pull requests no confiables. Da a un token de flujo de trabajo solo los permisos que su tarea necesita.
GitHub recomienda el anclaje por SHA de commit completo para la selección inmutable de actions. Revisa la action seleccionada y las actualizaciones posteriores; una etiqueta de versión puede moverse. Evita insertar datos de eventos no confiables directamente en código shell inline. Enmascarar valores de secretos conocidos no es una garantía contra la divulgación mediante transformaciones, registros o artefactos.
Referencia técnica: Uso seguro de GitHub Actions.
Usa vida útil corta cuando el destino lo soporte
OpenID Connect puede permitir a un destino soportado intercambiar la identidad del flujo de trabajo por una credencial de corta duración. Configura comprobaciones de confianza para el repositorio, la rama o el entorno y la audiencia previstos. Esto no es un reemplazo universal de SSH ni una función proporcionada por el frontend actual de PrivacyNodes.
Si tu despliegue usa SSH, revisa las opciones de claves autorizadas del paquete instalado. Un comando forzado por sí solo no prohíbe el reenvío; las restricciones deben cubrir las rutas de acceso previstas y aún así invocar una operación de versión segura. Prueba en un entorno separado. Conserva el acceso de administración y recuperación en funcionamiento mientras cambias la autenticación, y verifica una conexión independiente nueva antes de eliminar el método antiguo.
Referencia técnica: OpenID Connect de GitHub Actions · Formato de OpenSSH authorized_keys.
Prueba el trabajo permitido y el prohibido
Verifica que la identidad pueda seleccionar el artefacto previsto, invocar la versión y obtener un resultado útil. Luego prueba sus límites: los secretos de otra aplicación, cambios de archivos no relacionados y la administración arbitraria deben estar no disponibles. Incluye rutas de artefactos y argumentos que el wrapper debe rechazar.
Registra la identidad, el alcance, la caducidad cuando corresponda, el mantenedor aprobador y la ubicación de la evidencia de auditoría. Conserva referencias de almacenamiento en lugar de valores de credenciales. Si una prueba solo funciona tras conceder administración amplia, revisa la tarea de versión en lugar de convertirla silenciosamente en el rol permanente.
Ensaya la revocación y una versión con pipeline roto
Prepara un reemplazo con el alcance revisado, verifica un despliegue de prueba, cambia el pipeline y revoca la identidad antigua. Confirma que la credencial sustituida falla y que no queda ningún duplicado en otro flujo de trabajo. Añadir una nueva clave por sí solo no elimina el acceso anterior.
Documenta cómo un mantenedor autorizado detiene el despliegue y se recupera cuando CI no está disponible. Enlaza ese procedimiento con el registro de publicación y inventario de recuperación. Una credencial acotada limita la autoridad prevista; no hace inofensivo un artefacto malicioso.
Referencias oficiales
La documentación fue revisada para este artículo. Los ejemplos son ejercicios de planificación, no comandos probados en un servidor PrivacyNodes. Consulta la documentación de tu versión instalada.