Identité des runs

Plutôt que de conserver des clés de longue durée comme secrets, un run peut prouver à quelle organisation il appartient. Cadence.CI est un émetteur OpenID Connect : chaque run reçoit des jetons d’identité de courte durée, qu’AWS, Google Cloud, Azure, Vault et OpenBao acceptent une fois une relation de confiance établie, comme ils acceptent les jetons des jobs GitHub Actions et GitLab CI.

Obtenir un jeton

Sur un worker Cadence.CI, le localisateur api-id:<audience> donne le jeton d’identité du run pour une audience, en Secret<string> : api-id:sts.amazonaws.com pour AWS, api-id:vault pour un rôle Vault lié à l’audience vault. Passez-le à l’élément qui l’échange contre un accès, comme n’importe quel secret.

Un jeton est valable 10 minutes ; le moteur en demande un nouveau une fois qu’il a expiré. Comme api:, api-id: ne fonctionne que sur les workers Cadence.CI, et le jeton n’est jamais affiché.

Émetteur

Claims

Le sujet est le même pour tous les runs privés d’une organisation, pour que les fournisseurs qui le comparent exactement, comme AWS et Azure, fassent confiance à l’organisation dans son ensemble. Les conditions sur les tags ou les runs passent par les autres claims, là où le fournisseur peut les tester, comme Google Cloud, Vault et OpenBao. Les runs publics, et les runs qu’ils lancent, ont un sujet à part : une relation de confiance établie pour organization:<organization-id> ne les accepte jamais. Gardez-le ainsi pour tout ce qui est sensible, car les runs publics exécutent du code que n’importe qui peut proposer.

L’identifiant de votre organisation figure sur la page Organisation du tableau de bord.

AWS

1. Dans IAM, sous Identity providers, ajoutez un fournisseur OpenID Connect avec l’URL https://api.melodium.tech et l’audience sts.amazonaws.com.
2. Créez un rôle pour ce fournisseur, avec une politique de confiance limitée à votre organisation :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<account-id>:oidc-provider/api.melodium.tech"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "api.melodium.tech:aud": "sts.amazonaws.com",
          "api.melodium.tech:sub": "organization:<organization-id>"
        }
      }
    }
  ]
}

3. Dans le programme, donnez api-id:sts.amazonaws.com à ce qui endosse le rôle avec AssumeRoleWithWebIdentity, avec l’ARN du rôle.

Google Cloud

1. Créez un pool d’identités de charge de travail, et un fournisseur qui fait confiance aux runs de votre organisation :

gcloud iam workload-identity-pools create cadence-ci --location=global
 
gcloud iam workload-identity-pools providers create-oidc cadence-ci \
    --location=global \
    --workload-identity-pool=cadence-ci \
    --issuer-uri="https://api.melodium.tech" \
    --allowed-audiences="gcp" \
    --attribute-mapping="google.subject=assertion.sub,attribute.organization_id=assertion.organization_id" \
    --attribute-condition="assertion.organization_id == '<organization-id>' && !assertion.public"

2. Accordez les rôles dont les runs ont besoin à l’ensemble de principaux de l’organisation, principalSet://iam.googleapis.com/projects/<project-number>/locations/global/workloadIdentityPools/cadence-ci/attribute.organization_id/<organization-id>, ou laissez-le emprunter l’identité d’un compte de service avec roles/iam.workloadIdentityUser.
3. Dans le programme, demandez le jeton pour l’audience autorisée : api-id:gcp.

Azure

1. Sur une identité managée attribuée par l’utilisateur, ou sur une inscription d’application, ajoutez une information d’identification fédérée pour l’organisation :

az identity federated-credential create \
    --name cadence-ci \
    --identity-name <identity> \
    --resource-group <resource-group> \
    --issuer "https://api.melodium.tech" \
    --subject "organization:<organization-id>" \
    --audiences "api://AzureADTokenExchange"

2. Donnez à l’identité les rôles dont les runs ont besoin.
3. Dans le programme, demandez le jeton pour l’audience qu’attend Azure : api-id:api://AzureADTokenExchange.

Vault et OpenBao

1. Activez la méthode d’authentification jwt, en faisant confiance à Cadence.CI, et un rôle pour les runs de votre organisation (avec OpenBao, utilisez bao au lieu de vault) :

vault auth enable jwt
 
vault write auth/jwt/config \
    oidc_discovery_url="https://api.melodium.tech" \
    bound_issuer="https://api.melodium.tech"
 
vault write auth/jwt/role/cadence-ci - <<EOF
{
  "role_type": "jwt",
  "user_claim": "sub",
  "bound_audiences": ["vault"],
  "bound_subject": "organization:<organization-id>",
  "token_policies": ["ci"],
  "token_ttl": "10m"
}
EOF

2. Dans le programme, le modèle vault::Vault se connecte avec le jeton d’identité, et les secrets localisés vault:<chemin>#<champ> sont lus avec les politiques du rôle :

use sql::SqlPool
use std/ops/option::|wrap
use vault::Vault

treatment database(const password: Secret<string> = "vault:kv/data/app/db#password")
  model vault: Vault(address="https://vault.example.com:8200", auth="jwt", role="cadence-ci", jwt="api-id:vault")
  model pool: SqlPool(url="postgresql://app@db.example.com/app", password=|wrap<Secret<string>>(password))
{
}

bound_claims restreint encore le rôle, sur les autres claims, comme run_id ou tags.

Pour aller plus loin

• Secrets : enregistrer des secrets sur Cadence.CI.
• Clés.
• Package Vault  dans la référence Mélodium.