#Создайте Git Secret для PAC

Когда вы интегрируете репозиторий с PAC через Webhook (не через GitHub App), ресурс Repository ссылается на Kubernetes Secret, который хранит две группы учетных данных:

• Git access token — PAC использует его для вызова API Git-провайдера (чтение метаданных репозитория, публикация проверок commit/status, управление webhook).
• Webhook secret — Git-провайдер включает его при доставке события, чтобы PAC мог проверить, что запрос пришел из ожидаемого источника.

Это руководство создает этот Secret для режима GitHub Webhook и режима GitLab Webhook. Режиму GitHub App не нужен отдельный Secret для каждого репозитория, поскольку контроллер использует учетные данные App на уровне кластера.

#Как PAC читает Secret

PAC ищет Secret через поля Repository.spec.git_provider:

spec:
  git_provider:
    secret:
      name: <secret-name>
      key: provider.token       # default: provider.token
    webhook_secret:
      name: <secret-name>
      key: webhook.secret       # default: webhook.secret

• Если в secret поле key опущено, PAC читает provider.token.
• Если в webhook_secret поле key опущено, PAC читает webhook.secret.
• secret.name и webhook_secret.name могут указывать на один и тот же Secret или на два разных.

Secret должен находиться в том же namespace, что и ресурс Repository.

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

• Учетная запись Git-провайдера с правом создавать Personal Access Token (PAT) для репозитория.
• Целевой namespace для ресурса Repository.
• Доступ kubectl к этому namespace.

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

Создайте PAT у вашего Git-провайдера:

Скопируйте токен сразу. Большинство провайдеров показывают его только один раз.

#Шаг 2: Выберите webhook secret

Webhook secret — это общая строка между PAC и Git-провайдером. PAC проверяет входящие события по этому значению.

Можно использовать любую достаточно случайную строку, например сгенерированный пароль из менеджера паролей. Одно и то же значение должно храниться в Kubernetes Secret и быть настроено в webhook Git-провайдера.

Если хотите сгенерировать его из командной строки, один из вариантов — openssl:

openssl rand -hex 16

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

a4b1c2d3e4f5061718293a4b5c6d7e8f

Webhook secret необязателен, но настоятельно рекомендуется. Без него любой, кто узнает webhook URL, сможет подделывать события.

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

Создайте один Secret, который хранит оба значения под ключами по умолчанию. Замените:

• <git-access-token> на токен Git-провайдера из шага 1.

• <webhook-secret> на общую строку webhook secret из шага 2.

  kubectl create secret generic <secret-name> \
    --from-literal=provider.token='<git-access-token>' \
    --from-literal=webhook.secret='<webhook-secret>' \
    -n <your-namespace>

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

secret/my-repo-auth created

Либо создайте его из манифеста:

apiVersion: v1
kind: Secret
metadata:
  name: my-repo-auth
  namespace: project-pipelines
type: Opaque
stringData:
  provider.token: glpat-xxxxxxxxxxxxxxxxxxxx
  webhook.secret: a4b1c2d3e4f5061718293a4b5c6d7e8f

kubectl apply -f secret.yaml

#Шаг 4: Ссылайтесь на Secret из Repository

В ресурсе Repository укажите и git_provider.secret, и git_provider.webhook_secret на только что созданный Secret. Поскольку используются ключи по умолчанию, поле key можно опустить:

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
  namespace: project-pipelines
spec:
  url: https://gitlab.example.com/team/my-repo
  git_provider:
    type: gitlab
    secret:
      name: my-repo-auth
    webhook_secret:
      name: my-repo-auth

Если вы сохранили учетные данные под нестандартными ключами, явно задайте key в обоих полях.

#Проверка

Убедитесь, что Secret существует и содержит оба ключа:

kubectl get secret my-repo-auth -n <your-namespace> \
  -o jsonpath='{.data}' | jq 'keys'

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

["provider.token", "webhook.secret"]

После создания ресурса Repository PAC записывает успешный поиск в логах. Просмотрите последние записи логов контроллера в namespace PAC:

kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=50

Ошибка аутентификации ("401 Unauthorized", "invalid token") в логах контроллера указывает на неверный токен или токен с недостаточными scopes; см. Common Issues для полного контрольного списка по устранению неполадок.

#Обновление учетных данных

Выполните ротацию токена, обновив Secret на месте:

kubectl create secret generic my-repo-auth \
  --from-literal=provider.token='<new-token>' \
  --from-literal=webhook.secret='<existing-webhook-secret>' \
  -n <your-namespace> \
  --dry-run=client -o yaml | kubectl apply -f -

PAC читает Secret при каждом входящем событии, поэтому перезапуск контроллера не требуется.

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

• Настроить GitHub Repository
• Настроить GitLab Repository
• Получить PAC Webhook URL
• Common Issues