#Настройка аутентификации для частных репозиториев

В этом руководстве описано, как настроить аутентификацию для частных репозиториев в PAC. Для доступа PAC к содержимому репозитория и его клонирования частные репозитории требуют учетные данные для аутентификации.

#Предварительные требования

Перед настройкой аутентификации для частных репозиториев убедитесь, что у вас есть:

• Развернутый и запущенный компонент PAC
• Созданный для вашего репозитория Repository CR (Custom Resource). Repository CR — это ресурс Kubernetes, который сообщает PAC, какой Git-репозиторий отслеживать и как его настраивать
• Административный доступ для создания Kubernetes Secrets
• Токены доступа для вашего Git provider

#Обзор

PAC поддерживает аутентификацию для частных GitLab-репозиториев с использованием Personal Access Tokens (PAT) и HTTPS URL.

#Шаги настройки

Выполните следующие шаги, чтобы настроить аутентификацию для частных репозиториев.

#Шаг 1: Создайте access token в GitLab

1. Перейдите в GitLab → User Settings → Access Tokens
2. Создайте token с областью api
3. Сгенерируйте и скопируйте token

#Шаг 2: Создайте Kubernetes Secret

Создайте secret, содержащий ваш GitLab access token:

kubectl create secret generic gitlab-secret \
  --from-literal=token=your-gitlab-token-here \
  -n <your-namespace>

Пример вывода:

secret/gitlab-secret created

Примечание: PAC будет использовать этот token для операций API Git provider (управление webhook, обновление статусов PR и т. д.) и автоматически создаст на его основе secret аутентификации для git clone.

#Создание webhook secret (необязательно)

Если вы планируете настраивать webhook, создайте secret для проверки webhook:

kubectl create secret generic webhook-secret \
  --from-literal=secret=your-webhook-secret-here \
  -n <your-namespace>

Рекомендации по безопасности:

• Храните token’ы безопасно и используйте отдельные secrets для разных репозиториев или окружений
• PAC автоматически создает secrets аутентификации для git clone, поэтому создавать их вручную не требуется

#Шаг 3: Обновите Repository CR

Обновите ваш Repository CR, чтобы он ссылался на secret аутентификации:

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-private-repo
  namespace: project-pipelines
spec:
  url: "https://gitlab.com/user/private-repo"
  git_provider:
    type: gitlab
    url: "https://gitlab.com"
    secret:
      name: gitlab-secret
      key: token
    webhook_secret:
      name: webhook-secret
      key: secret

Примечание: PAC использует git_provider.secret для операций API и автоматически создает на его основе secret аутентификации для git clone, который используется в PipelineRuns.

#Проверка доступа к частному репозиторию

После настройки аутентификации убедитесь, что PAC может получить доступ к вашему частному репозиторию:

#Проверка Repository CR

kubectl get repository <repo-name> -n <your-namespace> -o yaml

Пример вывода (сокращенно):

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
  namespace: project-pipelines
spec:
  url: "https://gitlab.com/user/private-repo"
  git_provider:
    type: gitlab
    url: "https://gitlab.com"
    secret:
      name: gitlab-secret
      key: token

#Проверка логов PAC Controller

# Установите namespace для PAC (по умолчанию: tekton-pipelines)
PAC_NAMESPACE="tekton-pipelines"

kubectl logs -n ${PAC_NAMESPACE} \
  -l app=pipelines-as-code-controller \
  --tail=100

Ищите ошибки аутентификации или проблемы с подключением к вашему Git provider.

#Проверка запуска pipeline

Запустите тестовый pipeline, чтобы проверить доступ:

# Отправьте commit, чтобы запустить pipeline
git commit --allow-empty -m "Test private repo access"
git push origin main

Пример вывода:

[main abc1234] Test private repo access
Enumerating objects: 3, done.
Writing objects: 100% (2/2), 240 bytes | 240.00 KiB/s, done.
To https://gitlab.com/user/private-repo
   def5678..abc1234  main -> main

Проверьте, что PipelineRun создан успешно:

kubectl get pipelineruns -n <your-namespace>

Пример вывода:

NAME                    STARTED        DURATION   STATUS
simple-pipeline-xxxxx   1 minute ago  25s        Succeeded

#Устранение неполадок

#Проверка ошибок аутентификации

Проблема: PAC не может получить доступ к частному репозиторию.

Решения:

1. Проверьте права token: убедитесь, что GitLab access token имеет область api

2. Проверьте наличие secret: убедитесь, что GitLab secret существует в правильном namespace:

   kubectl get secret gitlab-secret -n <your-namespace>

   Пример вывода:

   NAME              TYPE     DATA   AGE
   gitlab-secret     Opaque   1      5m

3. Проверьте ключ secret: убедитесь, что secret содержит ключ token:

   kubectl get secret gitlab-secret -n <your-namespace> -o yaml

   Пример вывода (сокращенно, token закодирован в base64):

   apiVersion: v1
   kind: Secret
   metadata:
     name: gitlab-secret
     namespace: project-pipelines
   data:
     token: Z2xwYXQt...

4. Проверьте Repository CR: убедитесь, что ссылка на secret в Repository CR указана правильно:

   kubectl get repository <repo-name> -n <your-namespace> -o yaml | grep -A 5 git_provider

   Пример вывода:

   git_provider:
     type: gitlab
     url: "https://gitlab.com"
     secret:
       name: gitlab-secret
       key: token

#Истек срок действия token

Проблема: access token истек.

Решения:

1. Сгенерируйте новый access token в вашем Git provider

2. Обновите Kubernetes Secret:

   kubectl create secret generic gitlab-secret \
     --from-literal=token=new-token-here \
     -n <your-namespace> \
     --dry-run=client -o yaml | kubectl apply -f -

   Пример вывода:

   secret/gitlab-secret configured

3. При необходимости перезапустите pods PAC controller:

   kubectl rollout restart deployment pipelines-as-code-controller -n <tekton-namespace>  # Замените <tekton-namespace> на ваш фактический namespace (по умолчанию: tekton-pipelines)

   Пример вывода:

   deployment.apps/pipelines-as-code-controller restarted

#Рекомендации

#1. Управление token’ами

• Используйте отдельные token’ы: применяйте разные token’ы для разных репозиториев или окружений
• Устанавливайте срок действия: задавайте срок действия token’ов для повышения безопасности
• Регулярно выполняйте ротацию: периодически обновляйте access token’ы
• Ограничивайте области доступа: предоставляйте только минимально необходимые разрешения

#2. Управление secret’ами

• Используйте namespace’ы: храните secrets в соответствующих namespace’ах
• RBAC: используйте RBAC для контроля доступа к secret’ам
• External secrets: рассмотрите использование внешних средств управления secret’ами (например, Sealed Secrets, Vault)

#3. Безопасность

• Минимальные привилегии: предоставляйте только минимально необходимые разрешения
• Аудит доступа: регулярно проверяйте, у кого есть доступ к репозиториям
• Мониторинг логов: отслеживайте логи PAC controller на наличие проблем с аутентификацией

#Следующие шаги

• Настройка пользовательских сертификатов - Настройка пользовательских CA certificates для self-signed certificates
• Расширенная конфигурация репозитория - Ознакомьтесь с расширенными параметрами конфигурации репозитория
• Настройка GitLab Repository - Руководство по настройке для GitLab
• Распространенные проблемы - Руководство по устранению неполадок