Vue d’ensemble
OpenID Connect (OIDC) permet à vos flux de travail GitHub Actions de s’authentifier auprès de JFrog pour télécharger et publier des artefacts sans stocker les mots de passe, jetons ou clés API de JFrog dans GitHub.
Ce guide donne une vue d’ensemble de la manière de configurer JFrog pour qu’il fasse confiance à OIDC de GitHub en tant qu’identité fédérée. Il montre également comment utiliser cette configuration dans un flux de travail GitHub Actions.
Pour un exemple de flux de travail GitHub Actions, consultez Exemple d’intégration GitHub Actions dans la documentation JFrog.
Pour un exemple de flux de travail GitHub Actions utilisant la CLI de JFrog, consultez build-publish.yml
dans le référentiel jfrog-github-oidc-example
.
Prérequis
-
Pour en savoir plus sur les concepts de base décrivant la façon dont GitHub utilise OIDC (OpenID Connect) ainsi que sur son architecture et ses avantages, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».
-
Avant de continuer, vous devez planifier votre stratégie de sécurité pour veiller à ce que les jetons d’accès soient uniquement alloués de manière prévisible. Pour contrôler la façon dont votre fournisseur de cloud émet des jetons d’accès, vous devez définir au moins une condition, afin que les dépôts non approuvés ne puissent pas demander de jetons d’accès à vos ressources cloud. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».
-
Si vous suivez ce guide sur GHE.com, sachez que vous devez remplacer certaines valeurs dans la documentation suivante. Consultez « À propos du renforcement de la sécurité avec OpenID Connect ».
-
Pour être sécurisé, vous devez définir un JSON de revendications dans JFrog lors de la configuration des mappages d’identité. Pour plus d’informations, consultez « AUTOTITLE » et « À propos du renforcement de la sécurité avec OpenID Connect ».
Par exemple, vous pouvez définir
iss
surhttps://token.actions.githubusercontent.com
, et lerepository
sur quelque chose comme « octo-org/octo-repo. »` Vous serez ainsi assuré que seuls les flux de travail Actions du référentiel spécifié auront accès à votre plateforme JFrog. Voici un exemple de JSON de revendications lors de la configuration des mappages d’identité.JSON { "iss": "https://token.actions.githubusercontent.com", "repository": "octo-org/octo-repo" }
{ "iss": "https://token.actions.githubusercontent.com", "repository": "octo-org/octo-repo" }
Ajout du fournisseur d’identité à JFrog
Pour utiliser OIDC avec JFrog, établissez une relation d’approbation entre GitHub Actions et la plateforme JFrog. Pour plus d’informations sur ce processus, consultez OpenID Connect Integration dans la documentation JFrog.
- Connectez-vous à votre plateforme JFrog.
- Configurez l’approbation entre JFrog et vos flux de travail GitHub Actions.
- Configurer les mappages d'identité.
Mise à jour de votre workflow GitHub Actions
Une fois que vous avez établi une relation d’approbation entre GitHub Actions et la plateforme JFrog, vous pouvez mettre à jour votre fichier de flux de travail GitHub Actions.
Dans votre fichier de flux de travail GitHub Actions, assurez-vous que vous utilisez le nom du fournisseur et l’audience que vous avez configurés dans la plateforme JFrog.
L’exemple suivant utilise l’espace réservé YOUR_PROVIDER_NAME
.
- name: Fetch Access Token from Artifactory
id: fetch_access_token
env:
ID_TOKEN: $
run: |
ACCESS_TOKEN=$(curl \
-X POST \
-H "Content-type: application/json" \
https://example.jfrog.io/access/api/v1/oidc/token \
-d \
"{\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\", \"subject_token_type\":\"urn:ietf:params:oauth:token-type:id_token\", \"subject_token\": \"$ID_TOKEN\", \"provider_name\": \"YOUR_PROVIDER_NAME\"}" | jq .access_token | tr -d '"')
echo ACCESS_TOKEN=$ACCESS_TOKEN >> $GITHUB_OUTPUT
L’exemple suivant montre une partie d’un fichier de flux de travail GitHub Actions utilisant cURL.
- name: Get ID Token (cURL method)
id: idtoken
run: |
ID_TOKEN=$(curl -sLS -H "User-Agent: actions/oidc-client" -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=jfrog-github" | jq .value | tr -d '"')
echo "ID_TOKEN=${ID_TOKEN}" >> $GITHUB_OUTPUT
Vous pouvez également définir l’audience en tant que variable d’environnement à l’aide du contexte env
. Pour plus d’informations sur le contexte env
, consultez « Accès à des informations contextuelles sur l’exécution d’un workflow ».
Remarque : lorsque des environnements sont utilisés dans des workflows ou dans des stratégies OIDC, nous vous recommandons d’ajouter des règles de protection à l’environnement pour plus de sécurité. Par exemple, vous pouvez configurer des règles de déploiement sur un environnement pour restreindre les branches et balises pouvant être déployées dans l’environnement ou accéder aux secrets d’environnement. Pour plus d’informations, consultez « Gestion des environnements pour le déploiement ».
jobs:
build:
runs-on: ubuntu-latest
env:
OIDC_AUDIENCE: 'YOUR_AUDIENCE'
Ensuite, dans votre fichier de flux de travail, récupérez la valeur des variables stockées dans le contexte env
. L’exemple suivant utilise le contexte env
pour récupérer l’audience OIDC.
- name: Get ID Token (using env context)
uses: actions/github-script@v6
id: idtoken
with:
script: |
const coredemo = require('@actions/core');
let id_token = await coredemo.getIDToken(process.env.OIDC_AUDIENCE);
coredemo.setOutput('id_token', id_token);