Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.15. Authentification des pipelines avec git secret

Un secret Git consiste en des informations d'identification permettant d'interagir de manière sécurisée avec un dépôt Git, et est souvent utilisé pour automatiser l'authentification. Dans Red Hat OpenShift Pipelines, vous pouvez utiliser les secrets Git pour authentifier les exécutions de pipeline et les exécutions de tâches qui interagissent avec un dépôt Git pendant l'exécution.

Une exécution de pipeline ou une exécution de tâche accède aux secrets par le biais du compte de service associé. OpenShift Pipelines prend en charge l'utilisation des secrets Git en tant qu'annotations (paires clé-valeur) pour l'authentification de base et l'authentification basée sur SSH.

3.15.1. Sélection des diplômes
Copier lien

L'exécution d'un pipeline ou d'une tâche peut nécessiter plusieurs authentifications pour accéder à différents dépôts Git. Annotez chaque secret avec les domaines où OpenShift Pipelines peut utiliser ses informations d'identification.

Une clé d'annotation de credential pour les secrets Git doit commencer par tekton.dev/git-, et sa valeur est l'URL de l'hôte pour lequel vous voulez qu'OpenShift Pipelines utilise ce credential.

Dans l'exemple suivant, OpenShift Pipelines utilise un secret basic-auth, qui repose sur un nom d'utilisateur et un mot de passe, pour accéder aux dépôts à github.com et gitlab.com.

Exemple : Plusieurs informations d'identification pour l'authentification de base

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username:
1 

  password:
2
Copy to Clipboard Toggle word wrap

1
Nom d'utilisateur pour le référentiel
2
Mot de passe ou jeton d'accès personnel au référentiel

Vous pouvez également utiliser un secret ssh-auth (clé privée) pour accéder à un dépôt Git.

Exemple : Clé privée pour l'authentification basée sur SSH

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey:
1
Copy to Clipboard Toggle word wrap

1
Le contenu du fichier de clé privée SSH.

3.15.2. Configuration de l'authentification de base pour Git
Copier lien

Pour qu'un pipeline puisse récupérer des ressources dans des référentiels protégés par mot de passe, vous devez configurer l'authentification de base pour ce pipeline.

Pour configurer l'authentification de base pour un pipeline, mettez à jour les fichiers secret.yaml, serviceaccount.yaml, et run.yaml avec les informations d'identification du secret Git pour le référentiel spécifié. Lorsque vous avez terminé ce processus, OpenShift Pipelines peut utiliser ces informations pour récupérer les ressources de pipeline spécifiées.

Note

Pour GitHub, l'authentification par mot de passe simple est obsolète. Utilisez plutôt un jeton d'accès personnel.

Procédure

  1. Dans le fichier secret.yaml, spécifiez le nom d'utilisateur et le mot de passe ou le jeton d'accès personnel GitHub pour accéder au dépôt Git cible. 

    apiVersion: v1
kind: Secret
metadata:
  name: basic-user-pass
    1 
    
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username:
    2 
    
  password:
    3
    Copy to Clipboard Toggle word wrap
    1
    Nom du secret. Dans cet exemple, basic-user-pass.
    2
    Nom d'utilisateur pour le dépôt Git.
    3
    Mot de passe pour le dépôt Git.

  2. Dans le fichier serviceaccount.yaml, associez le secret au compte de service approprié. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot
    1 
    
secrets:
  - name: basic-user-pass
    2
    Copy to Clipboard Toggle word wrap
    1
    Nom du compte de service. Dans cet exemple, build-bot.
    2
    Nom du secret. Dans cet exemple, basic-user-pass.

  3. Dans le fichier run.yaml, associez le compte de service à une exécution de tâche ou de pipeline.

    • Associer le compte de service à l'exécution d'une tâche : 

      apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: build-push-task-run-2
      1 
      
spec:
  serviceAccountName: build-bot
      2 
      
  taskRef:
    name: build-push
      3
      Copy to Clipboard Toggle word wrap
      1
      Nom de la tâche exécutée. Dans cet exemple, build-push-task-run-2.
      2
      Nom du compte de service. Dans cet exemple, build-bot.
      3
      Nom de la tâche. Dans cet exemple, build-push.

    • Associer le compte de service à une ressource PipelineRun: 

      apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: demo-pipeline
      1 
      
  namespace: default
spec:
  serviceAccountName: build-bot
      2 
      
  pipelineRef:
    name: demo-pipeline
      3
      Copy to Clipboard Toggle word wrap
      1
      Nom de l'exécution du pipeline. Dans cet exemple, demo-pipeline.
      2
      Nom du compte de service. Dans cet exemple, build-bot.
      3
      Nom du pipeline. Dans cet exemple, demo-pipeline.

  4. Appliquez les modifications. 

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
    Copy to Clipboard Toggle word wrap

3.15.3. Configuration de l'authentification SSH pour Git
Copier lien

Pour qu'un pipeline puisse récupérer des ressources à partir de référentiels configurés avec des clés SSH, vous devez configurer l'authentification basée sur SSH pour ce pipeline.

Pour configurer l'authentification basée sur SSH pour un pipeline, mettez à jour les fichiers secret.yaml, serviceaccount.yaml, et run.yaml avec les informations d'identification de la clé privée SSH pour le référentiel spécifié. Lorsque vous avez terminé ce processus, OpenShift Pipelines peut utiliser ces informations pour récupérer les ressources de pipeline spécifiées.

Note

Envisagez d'utiliser l'authentification SSH plutôt que l'authentification de base.

Procédure

  1. Générer une clé privée SSH ou copier une clé privée existante, qui est généralement disponible dans le fichier ~/.ssh/id_rsa.

  2. Dans le fichier secret.yaml, définissez la valeur de ssh-privatekey comme étant le contenu du fichier de clé privée SSH, et définissez la valeur de known_hosts comme étant le contenu du fichier d'hôtes connus. 

    apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
    1 
    
  annotations:
    tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey:
    2 
    
  known_hosts:
    3
    Copy to Clipboard Toggle word wrap
    1
    Nom du secret contenant la clé privée SSH. Dans cet exemple, ssh-key.
    2
    Le contenu du fichier de clé privée SSH.
    3
    Le contenu du fichier des hôtes connus.
    Important

    Si vous omettez la clé privée, OpenShift Pipelines accepte la clé publique de n'importe quel serveur.

  3. Facultatif : Pour spécifier un port SSH personnalisé, ajoutez :<port number> à la fin de la valeur annotation. Par exemple, tekton.dev/git-0: github.com:2222.

  4. Dans le fichier serviceaccount.yaml, associez le secret ssh-key au compte de service build-bot. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot
    1 
    
secrets:
  - name: ssh-key
    2
    Copy to Clipboard Toggle word wrap
    1
    Nom du compte de service. Dans cet exemple, build-bot.
    2
    Nom du secret contenant la clé privée SSH. Dans cet exemple, ssh-key.

  5. Dans le fichier run.yaml, associez le compte de service à une exécution de tâche ou de pipeline.

    • Associer le compte de service à l'exécution d'une tâche : 

      apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: build-push-task-run-2
      1 
      
spec:
  serviceAccountName: build-bot
      2 
      
  taskRef:
    name: build-push
      3
      Copy to Clipboard Toggle word wrap
      1
      Nom de la tâche exécutée. Dans cet exemple, build-push-task-run-2.
      2
      Nom du compte de service. Dans cet exemple, build-bot.
      3
      Nom de la tâche. Dans cet exemple, build-push.

    • Associer le compte de service à un pipeline : 

      apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: demo-pipeline
      1 
      
  namespace: default
spec:
  serviceAccountName: build-bot
      2 
      
  pipelineRef:
    name: demo-pipeline
      3
      Copy to Clipboard Toggle word wrap
      1
      Nom de l'exécution du pipeline. Dans cet exemple, demo-pipeline.
      2
      Nom du compte de service. Dans cet exemple, build-bot.
      3
      Nom du pipeline. Dans cet exemple, demo-pipeline.

  6. Appliquez les modifications. 

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
    Copy to Clipboard Toggle word wrap

Lorsque vous invoquez des commandes Git, vous pouvez utiliser l'authentification SSH directement dans les étapes d'une tâche. L'authentification SSH ignore la variable $HOME et utilise uniquement le répertoire personnel de l'utilisateur spécifié dans le fichier /etc/passwd. Chaque étape d'une tâche doit donc établir un lien symbolique entre le répertoire /tekton/home/.ssh et le répertoire personnel de l'utilisateur associé.

Cependant, les liens symboliques explicites ne sont pas nécessaires lorsque vous utilisez une ressource de pipeline du type git, ou la tâche git-clone disponible dans le catalogue Tekton.

Pour un exemple d'utilisation de l'authentification SSH dans les tâches de type git, voir authenticating-git-commands.yaml.

3.15.5. Utiliser des secrets en tant qu'utilisateur non root
Copier lien

Il se peut que vous deviez utiliser des secrets en tant qu'utilisateur non root dans certains cas, par exemple :

  • Les utilisateurs et les groupes que les conteneurs utilisent pour exécuter des tâches sont choisis au hasard par la plateforme.
  • Les étapes d'une tâche définissent un contexte de sécurité non racine.
  • Une tâche spécifie un contexte de sécurité global non racine, qui s'applique à toutes les étapes d'une tâche.

Dans de tels scénarios, il convient de prendre en compte les aspects suivants de l'exécution des tâches et des pipelines en tant qu'utilisateur non root :

  • L'authentification SSH pour Git exige que l'utilisateur ait un répertoire personnel valide configuré dans le répertoire /etc/passwd. La spécification d'un UID qui n'a pas de répertoire personnel valide entraîne l'échec de l'authentification.
  • L'authentification SSH ignore la variable d'environnement $HOME. Vous devez donc créer un lien symbolique entre les fichiers secrets appropriés du répertoire $HOME défini par OpenShift Pipelines (/tekton/home) et le répertoire personnel valide de l'utilisateur non root.

En outre, pour configurer l'authentification SSH dans un contexte de sécurité non root, reportez-vous à l'exemple d'authentification des commandes git.

Par défaut, les secrets pour OpenShift Pipelines sont stockés dans le répertoire $HOME/tekton/home, et sont disponibles pour toutes les étapes d'une tâche.

Pour limiter un secret à des étapes spécifiques, utilisez la définition du secret pour spécifier un volume et montez le volume dans des étapes spécifiques.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat