Authentification d'ARC pour l'API GitHub

Authentifiez Actions Runner Controller auprès de l’API GitHub.

Dans cet article

Vous pouvez authentifier Actions Runner Controller (ARC) auprès de l’API GitHub à l’aide d’une GitHub App ou d’un personal access token (classic).

Remarque

L’authentification à l’aide d’un GitHub App n’est pas prise en charge pour les runners configurés au niveau de l’entreprise. Pour plus d’informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».

Authentification d’ARC avec une GitHub App

  1. Créez une GitHub App appartenant à une organisation. Pour plus d’informations, consultez « Inscription d’une application GitHub ». Configurez l’GitHub App comme suit.

    1. Pour « URL de la page d’accueil », entrez https://github.com/actions/actions-runner-controller.

    2. Sous « Autorisations », cliquez sur Autorisations du dépôt. Utilisez ensuite les menus déroulants pour sélectionner les autorisations d’accès suivantes. * Administration : Lecture et écriture

      Remarque

          `Administration: Read and write` n'est nécessaire que lorsque l'on configure Actions Runner Controller pour qu'il s'enregistre au niveau du référentiel. Il n’est pas nécessaire de s’inscrire au niveau de l’organisation.

      •   **Métadonnées** : Lecture seule

    3. Sous « Autorisations », cliquez sur Autorisations de l’organisation. Utilisez ensuite les menus déroulants pour sélectionner les autorisations d’accès suivantes. * Exécuteurs auto-hébergés : Lecture et écriture

  2. Après avoir créé GitHub App, dans la page de GitHub App, notez la valeur « ID d’application ». Vous utiliserez cette valeur plus tard.

  3. Sous « Clés privées », cliquez sur Générer une clé privée et enregistrez le fichier .pem. Vous utiliserez cette clé plus tard.

  4. Dans le menu en haut à gauche de la page, cliquez sur Installer l’application, puis à côté de votre organisation, cliquez sur Installer pour installer l’application dans votre organisation.

  5. Après avoir confirmé les autorisations d’installation sur votre organisation, notez l’ID d’installation de l’application. Vous le réutiliserez ultérieurement. Vous trouverez l’ID d’installation de l’application dans la page d’installation de l’application, qui a le format d’URL suivant :

    https://github.com/organizations/ORGANIZATION/settings/installations/INSTALLATION_ID

Authentification d’ARC avec un personal access token (classic)

ARC peut utiliser des personal access tokens (classic) pour enregistrer des runners auto-hébergés.

Remarque

Pour enregistrer des runners au niveau de l’entreprise, l’authentification ARC via un personal access token (classic) constitue la seule méthode prise en charge.

  1. Créez un personal access token (classic) avec les étendues requises. Les étendues requises varient selon que vous inscrivez des exécuteurs au niveau du dépôt, de l’organisation ou de l’entreprise. Pour plus d’informations sur la création d’un personal access token (classic), consultez « Gestion de vos jetons d’accès personnels ».

    Voici la liste des périmètres de personal access token requis pour les exécuteurs ARC.

    • Exécuteurs de dépôt : repo
    • Exécuteurs d’organisation : admin:org
    • Exécuteurs d’entreprise : manage_runners:enterprise

  2. Pour créer un secret Kubernetes avec les valeurs de votre personal access token (classic), utilisez la commande suivante.

    Remarque

    Créez le secret dans le même espace de noms que celui où le graphique gha-runner-scale-set est installé. Dans cet exemple, l’espace de noms est arc-runners, de sorte correspondre à la documentation de démarrage rapide. Pour plus d’informations, consultez « Prise en main du contrôleur Runner Actions ».

    Bash
    kubectl create secret generic pre-defined-secret \
   --namespace=arc-runners \
   --from-literal=github_token='YOUR-PAT'

  3. Dans votre copie du fichier values.yaml, passez le nom du secret en tant que référence.

    githubConfigSecret: pre-defined-secret

    Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Authentification ARC avec fine-grained personal access token

ARC peut s’appuyer sur des fine-grained personal access tokens afin d’enregistrer des runners auto-hébergés.

Remarque

Pour enregistrer des runners au niveau de l’entreprise, l’authentification ARC via un personal access token (classic) constitue la seule méthode prise en charge.

  1. Créez un fine-grained personal access token avec les étendues requises. Les étendues requises varient selon que vous enregistrez des runners au niveau du référentiel ou de l’organisation. Pour plus d’informations sur la création d’un fine-grained personal access token, consultez Gestion de vos jetons d’accès personnels.

    Voici la liste des périmètres de personal access token requis pour les exécuteurs ARC.

    • Exécuteurs de dépôt : * Administration : Lecture et écriture

    • Gestionnaires d'organisation * Administration : Lire * Exécuteurs auto-hébergés : Lecture et écriture

  2. Pour créer un secret Kubernetes avec les valeurs de votre fine-grained personal access token, utilisez la commande suivante.

    Remarque

    Créez le secret dans le même espace de noms que celui où le graphique gha-runner-scale-set est installé. Dans cet exemple, l’espace de noms est arc-runners, de sorte correspondre à la documentation de démarrage rapide. Pour plus d’informations, consultez « Prise en main du contrôleur Runner Actions ».

    Bash
    kubectl create secret generic pre-defined-secret \
   --namespace=arc-runners \
   --from-literal=github_token='YOUR-PAT'

  3. Dans votre copie du fichier values.yaml, passez le nom du secret en tant que référence.

    githubConfigSecret: pre-defined-secret

    Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Authentification ARC à l’aide de secrets de coffre-fort

Remarque

L'intégration du coffre est actuellement disponible en préversion publique avec prise en charge d'Azure Key Vault.

À compter de gha-runner-scale-set version 0.12.0, ARC prend en charge la récupération des informations d’identification GitHub à partir d’un coffre externe. L’intégration de la gestion des coffres est configurée par ensemble d'exécuteurs pour la mise à l'échelle. Cela signifie que vous pouvez exécuter certains lots de mise à l'échelle utilisant des secrets Kubernetes tandis que d'autres utilisent des secrets basés sur un coffre-fort, selon vos exigences en matière de sécurité et d'opérations.

Activation de l’intégration Vault

Pour activer l’intégration du coffre pour un ensemble de groupes d’exécuteurs :

  1.        **Définissez le champ `githubConfigSecret`** dans votre fichier `values.yaml` sur le nom de la clé secrète stockée dans votre coffre. Cette valeur doit être une chaîne.
  2. c1Retirez les commentaires et configurez la section dans votre fichier avec les informations relatives au fournisseur et aux détails d’accès appropriés.
  3.           **Fournissez le certificat requis** (`.pfx`) au contrôleur et à l’écouteur. Pour ce faire, vous pouvez : *Regénérer l’image du contrôleur en y incluant le certificat, ou *Monter le certificat en tant que volume dans le contrôleur et l’écouteur à l’aide des champs `listenerTemplate` et `controllerManager`.

Format du secret

Le secret stocké dans Azure Key Vault doit être au format JSON. La structure dépend du type d’authentification que vous utilisez :

Exemple : jeton GitHub

{
  "github_token": "TOKEN"
}

Exemple : application GitHub

{
  "github_app_id": "APP_ID_OR_CLIENT_ID",
  "github_app_installation_id": "INSTALLATION_ID",
  "github_app_private_key": "PRIVATE_KEY"
}

Configuration de values.yaml pour l’intégration de Vault

Le certificat est stocké dans un fichier .pfx et monté dans le conteneur à l’emplacement /akv/cert.pfx. Voici un exemple de configuration de la section keyVault pour utiliser ce certificat pour l’authentification :

keyVault:
  type: "azure_key_vault"
  proxy:
    https:
      url: "PROXY_URL"
      credentialSecretRef: "PROXY_CREDENTIALS_SECRET_NAME"
    http: {}
    noProxy: []
  azureKeyVault:
    clientId: <AZURE_CLIENT_ID>
    tenantId: <AZURE_TENANT_ID>
    url: <AZURE_VAULT_URL>
    certificatePath: "/akv/cert.pfx"

Fourniture du certificat au contrôleur et à l’écouteur

ARC requiert un certificat .pfx pour s’authentifier auprès du coffre-fort. Ce certificat doit être mis à la disposition des composants contrôleur et écouteur lors de l’installation du contrôleur. Vous pouvez le faire en montant le certificat comme volume à l’aide des champs controllerManager et listenerTemplate dans votre fichier values.yaml :

volumes:
  - name: cert-volume
    secret:
      secretName: my-cert-secret
volumeMounts:
  - mountPath: /akv
    name: cert-volume
    readOnly: true

listenerTemplate:
  volumeMounts:
    - name: cert-volume
      mountPath: /akv/certs
      readOnly: true
  volumes:
    - name: cert-volume
      secret:
        secretName: my-cert-secret

Le code ci-dessous est un exemple de fichier d'ensemble d'échelles values.yml.

listenerTemplate:
  spec:
    containers:
      - name: listener
        volumeMounts:
          - name: cert-volume
            mountPath: /akv
            readOnly: true
    volumes:
      - name: cert-volume
        secret:
          secretName: my-cert-secret

Certaines parties ont été adaptées à partir de https://github.com/actions/actions-runner-controller/ sous la licence Apache-2.0 :

Copyright 2019 Moto Ishizawa

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.