GitLab k8s runner даёт ошибку " failed to verify certificate: x509: certificate signed by unknown authority" во время регистрации на сервере

Довольно долго провозился с этой темой.

Как оказалось проблема не в сертификате (его содержимом).

Основная история вот в чём:

1. сертификат долженг иметь такое же имя, как вы указали в параметре tls-ca-file файла /etc/gilab-runner/config.toml

2. после создания секрета в k8s, в values.yaml  создайте две переменные окружения 

envVars:

  - name: <secret_name>
    value: /home/gitlab-runner/.gitlab-runner/certs/<certificate_name>

P.S. после этого, если на runner выскакивает ошибка kubectl  с аналогичным кодом - просто добавьте "--insecure-skip-tls-verify."

 

Small note on git clone issue

 git clone https://some_fqdn/development-group/k8sdemo.git

Клонирование в «k8sdemo»...

Username for 'https://some_fqdn':

Password for 'https://some_fqdn':

remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See https://devops.test-lab.ru/help/topics/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied

Просто добавь "git clone https://gitlab_user_name@some_fqdn/development-group/k8sdemo.git" и исполоьзуй Private Access Token (PAT). Либо переводи на ssh.

Веселье перевода GitLab на https и другие пляски

Продолжение приключений в лабе.

В общем, столкнулся с такой бедой, что k8s runner Gitlab требует наличия https и доп. ключи в командах не помогают. Подробнее можно ознакомиться тут.

"Yes, kubectl would never send credentials over a cleartext connection. --insecure-skip-tls-verify wouldn't help, it just disables TLS verification, but TLS is still required for it to send credentials."

Смысл проблемы понятен и я стал переводить лабу на https, выпустив сертификат самоподписанный для сервера GitLab и всех необходимых SAN (Subject Alternative Name).

После того, как я настроил https на сервере, естественно отвалился KAS (k8s agent server) GitLab, ибо он был настрое для http. Следом отвалилась Visual Studio Code, отказывающаяся принимать самопдписанный серт. 

Первое я починил сделав несколько приседаний с размещением сертификатов в /usr/local/shara/ca-certificates на серверах k8s и GitLab, с последующей коммандой sudo update-ca-trust. В Helm вызове обвноления развёртывания KAS необходимо было указать 

--set-file config.kasCert=/opt/<cert_name.crt> и --set config.kasAddress=wss://<gitlab.domain.ru>/-/kubernetes-agent/  (может использоваться ссылка =ws://, если мы говорим о http), внести в /etc/gitlab-runner/config.toml директиву tls-ca-file="/usr/local/shara/ca-certificates/<cert_name.crt>" в секции [[runners]]. После этого KAS позеленел (при обновлении стоит не забывать актуализировать версию агента - я про это забыл и потерял некоторое кол-во времени дополнительно, поймав рассинхрон между сервером GitLab и KAS по версиям). 

Второе же, почилилось без сложных приседаний: я нашел рекомендацию, где сказано, что надо отключить "HTTP: Proxy support", что и проделал. Детали можно посмотреть тут. 

Осталось починить runners, пока pipeline зависает, т.к. runners потеряли gitlab сервер.

Продолжаем-с....

P.S. А, забыл, Container Registry тоже отлетел. Не забываем менять /etc/gitlab/gitlab.rb в части registry_external_url 'https://<gitlab.domain.ru>:<port_number>', после выполнения команд из предыдущей статьи nginx упал с ошибкой.

[ladmin@k8srepo ~]$ sudo gitlab-ctl status nginx

down: nginx: 1s, normally up, want up; run: log: (pid 1077) 1717

По-умолчанию, nginx пытается открыть файл ключа и сертификата с именем, как в выводе ниже.

 [emerg] 1920#0: cannot load certificate "/etc/gitlab/ssl/<gitlab.domain.ru>.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/gitlab/ssl/<server_fqdn>.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file)

Детализацию получил с помощью команды  sudo gitlab-ctl tail.

Отсюда и проблема, дериктивы  ssl_certificate и ssl_certificate_key - почему-то не зарешали. Смысл в том, что файлы сертификата и ключа имели другое имя. В общем, после того, как это поправил - всё взлетело.

Заметки о сосуществовании сервера GitLab и кластер Kubernetes

Забавно было пропасть на 3 года.

Ниже приведены заметки и личный субъективный опыт отработки взаимодействия k8s кластера и сервера GitLab - каждому своё.

• в своей лаборатории я разносил namespace для gitlab-agent и gitlab-runner, из плюсов - атамарное управление разными уровнями функциональной нагрузки:

[ladmin@k8sm01 k8sdemo]$ kubectl get namespaces | grep gitlab

gitlab-agent-k8s    Active   36d

gitlab-runners-ns   Active   52m

• правильные настройки в values.yaml  для установки gitlab-runner на k8s в части репозитария и образа:

image:
  registry: registry.gitlab.com
  image: gitlab-org/gitlab-runner
  tag: alpine-v17.6.0
версия образа - будет меняться по необходимости.

•  я использовал  встроенный в GitLab сервер Container Registry без использования SSL сертификатов - лень было делать в лаборатории. В результате я получал ImagePullBackOff при попытке развернуть что-либо с детализацией ошибки "server gave HTTP reply to HTTPS client". Исправил это путём модификации /etc/containerd/config.toml каждого узла кластера k8s.

        

    

    далее следует выполнить:

sudo systemctl restart containerd.service

• после обновления GitLab сервер необходимо также обновить GitLab agent на кластере k8s.

helm upgrade <release_name> gitlab/gitlab-agent  --namespace <k8s_namespace_name> --set image.tag=vX.Y.Z --set config.token=<your_token>  --set config.kasAddress=ws://devops.test-lab.ru/-/kubernetes-agent/ --set replicas=1

            Если забыть указать токен, то вы получите ошибку 

kubectl logs  k8s-gitlab-agent-v2-56777f97d6-dnbqq  -n gitlab-agent-k8s

{"time":"2025-01-04T10:21:36.816484327Z","level":"ERROR","msg":"Program aborted","error":"token file: open /etc/agentk/secrets/token: no such file or directory"}

• при конфигурации GitLab сервер для использования Container Registry я допустил ошибку, использовав один и тот же порт для нескольких элементов GitLab. Ошибку удалось вычислить по записи в /var/log/gitlab/registry/current.

sudo cat /var/log/gitlab/registry/current | tail -10

 

"2024-12-26_08:22:56.55672 time="2024-12-26T11:22:56.556+03:00" level=fatal msg="listen tcp 127.0.0.1:5005: bind: address already in use"

          Что было исправлено:

    Далее необходимо выполнить команды ниже, иначе ошибка никуда не уйдёт (по-моему, "gitlab-ctl reconfigure" будет достаточно):

sudo systemctl restart gitlab.target

sudo gitlab-ctl restart nginx

sudo gitlab-ctl reconfigure

sudo gitlab-ctl status

• если в секции ниже в values.yaml для gitlab runner значения параметров  "allowPrivilegeEscalation", "privileged" будут иметь разные значения - получите ошибку "cannot set `allowPrivilegeEscalation` to false and `privileged` to true". 

securityContext:

  allowPrivilegeEscalation: true

  readOnlyRootFilesystem: false

  runAsNonRoot: true

  privileged: true

  capabilities:

    drop: ["ALL"]

Нюанс работы с задачей " Azure Key Vault" в Azure DevOps

В своём проекте я столкнулся с необходимостью извлекать секреты из Azure Key Vault (AKV), который изолирован внутри виртуальной сети. Если коротко, то это очень частый сценарий, используемый для повышения безопасности сервисов Azure и AKV в частности.

Заметка: Self-hosted агент мы не рассматриваем.

Агенты Azure DevOps (AzDO) не являются доверенным сервисом для Azure, поэтому настройка "Allow Trusted Microsoft Services to bypass this firewall." для агентов AzDO не работает. 

Если вы использовали Variable groups для инъекции секретов в Pipelines/Release - они, при использовании изолированного AKV, работать перестанут.

В этом случае поможет комбинация задач, из которых: 

первая добавит публичный адрес агента AzDO  в список разрешенных на AKV, затем необходимо использовать отдельную задачу "Azure Key Vault" для извлечения списка секретов и их содержимого, ну и третья задача должна удалить публичный адрес агента из списка разрешенных.

Есть нюанс: обратите внимание на настройку "Make secrets available to whole job"

При сценарии, описанном выше, необходимо её выключить, иначе извлечения секретов будет выполняться как пред-задача, которая запуститься до того, как будут сделаны настройки файрвола AKV. Соотвественно вы получите ошибку ниже.

Неожиданные символы при работе с ARM template для API management

В одном из сценариев автоматизации мне понадобилось "на лету" менять значения в шаблонах для нескольких API, которые в последствии разворачивались в другое окружение.

Неожиданно для себя я получил какое-то невменяемое сообщение об ошибке а-ля неопознанные команды и т.д. Сначала я заглянул в шаблон через Notepad, но ничего не обнаружил, однако, каково было моё удивление, когда я открыл тот же шаблон в Visual Studio Code.

Изменения производились через PowerShell скрипт и он был всему виной. Другого объяснения у меня не было. 

Происходила замена символа одинарной кавычки на код.

Очень интересно то, что кодированные кавычки появлялись уже после чтения файла, а не после его сохранения.

Проблема решилась достаточно банально.

Get-AzApiManagementPolicy не возвращает политику для области API при наличии параметра -ApiId

Краткая заметка о работе с PowerShell Cmdlets для API management.

Замечено, что команда Get-AzApiManagementPolicy -ApiId "<api_id"> -Context $apimContext может не вернуть ничего в случае, когда политика для конкретного API имеет конфигурацию по-умолчанию.

Стоит добавить что-либо разумное и команда начинает возвращать состав политики.