Support keyless (workload identity) authentication for the AWS, Azure and Vault secrets backends

Abierto
#3,488 6 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
aws, azure, go

Línea de trabajo

The issue identifies AWS Secrets Manager, Azure Key Vault, and Vault credentials backends, but does not name implementation files or tests. Start by reading the backend implementations and their configuration tests, then compare their credential handling with the existing GCP workload identity support. Done means each backend accepts its keyless authentication option while existing static-credential configurations continue to work.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

component/artifact-cas enhancement

The credentials backends currently require a long-lived static credential for everything but GCP:

  • AWS Secrets Manager takes an access key and secret only.
  • Azure Key Vault takes a service principal client secret only.
  • Vault takes a static token only (config.proto noted that application role auth was wanted instead).

Operators on EKS, AKS, or with Vault/OpenBao in-cluster usually have a keyless option available: EKS Pod Identity or
IRSA, AKS Workload Identity, and Vault's Kubernetes auth method. Supporting those means no stored secret has to be
rotated for the control plane or CAS. GCP already works this way, since its credentials file can be a workload
identity federation configuration.

Each backend is proposed as a separate PR, so they can be reviewed and merged independently: #3486 (AWS), #3485
(Azure), #3487 (Vault). Every change is backwards compatible: existing static-credential configurations behave exactly
as before.

Lenguaje dominante
Go
Estrellas
582
Forks
61
Merge medio
12 h 47 min
PR fusionados (30 d)
137

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de chainloop-dev/chainloop

Todos los issues de chainloop-dev/chainloop

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.