Привет, Хабр!

Столкнулся по работе с интересной, на мой взгляд, ситуацией. Многим она может показаться банальной, но мне пришлось достаточно весомое время посидеть, чтобы разобраться.

Предыстория

Стояла довольно понятная задача — развернуть Helm-чарт через ArgoCD, конкретно речь идёт про Airflow. Часть данных в values чувствительна, например пароль от Postgres, поэтому её неплохо бы вынести во внешнее хранилище секретов. Мы используем для этого HashiCorp Vault.

Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительным по ряду причин является vault-injector, но основная причина для нас была в том, что ArgoCD image-updater на данный момент не умеет работать, если используются плагины, об особенности работы с которыми и пойдёт речь. В обычной ситуации я бы и воспользовался vault-injector, но в случае с чартом Airflow это показалось довольно сложной задачей, поэтому было принято решение воспользоваться менее предпочтительным, но точно рабочим (как я думал) вариантом с ArgoCD Vault Plugin.

Что за плагин такой

Не вдаваясь в детали, настроив этот плагин согласно инструкции вы получаете возможность инжектить секреты прямо в values, используя следующий синтаксис:

secret: <path:path/to/secret/in/vault#secret_key>

Если не обращать внимание на image-updater и на то, что секреты не будут обновляться внутри пода при обновлении их в Vault, то такой путь вполне приемлем.

Непосредственно проблема

Когда секреты были добавлены в хранилище и ArgoCD Application был написан, я попытался развернуть его для теста. Приведу примерный Application с которым это делалось (весомая часть пропущена для компактности):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: airflow
  labels:
    app.kubernetes.io/name: airflow
    app.kubernetes.io/component: airflow
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    namespace: some-namespace
    name: cluster
  source:
    repoURL: "airflow_repo_url"
    targetRevision: "revision"
    chart: airflow
    plugin:
      name: argocd-vault-plugin-helm
      env:
        - name: HELM_VALUES
          value: |
              ...
              metadataConnection:
                user: user
                pass: <path:path/to/airflow/secrets#postgres_password>
                protocol: postgresql
                host: postgres.db.url
                port: 5432
                db: airflow_db
                sslmode: prefer
              ...
     
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - Validate=true
      - CreateNamespace=true

Как видно, ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета.

К моему удивлению компонент webserver отказывался запускаться, ссылаясь на невозможность подключиться к базе данных, хотя в правильности данных я был абсолютно уверен. После долгого дебага я наконец решил посмотреть, что же лежит в Kubernetes Secret, который создаёт чарт и откуда берётся пароль. Вот, что я увидел:

apiVersion: v1
data:
  // base64 encoded
  postgres_password: %3Cpath%3Apath%2Fto%2Fairflow%2Fsecrets%23postgres_password%3E

При этом рядом был другой секрет, созданный этим же чартом, который расшифровался абсолютно корректно. После долгих попыток понять в чём же дело, я решил развернуть приложение иначе. Кроме прямого разворачивания Application есть и другой вариант - App of Apps. Подробнее можно почитать в официальной документации, но вкратце - это способ создать базовое приложение (ArgoCD Application), которое будет подтягивать из директории в Git-репозитории другие приложения, и о чудо - всё заработало как надо.

В чём же дело

После недолгих размышлений я заметил одну особенность — момент в который секреты непосредственно расшифровываются, а происходит это при создании того Application, в котором прописаны пути до секретов. То есть когда я создавал приложение напрямую, расшифровка происходила при развороте непосредственно Airflow, а в случае App of Apps - при разворачивании родительского приложения.

Этот факт дал мне понять, что первоначальный корень проблемы лежит где-то в самом чарте Airflow и я не прогадал.

Вот что мы видим в манифесте секрета metadata-connection:

connection: {{ urlJoin (dict "scheme" .protocol "userinfo" (printf "%s:%s" (.user | urlquery) (.pass | urlquery) ) "host" (printf "%s:%s" $host $port) "path" (printf "/%s" $database) "query" $query) | b64enc | quote }}

Согласно официальной документации Helm:

urlquery

Returns the escaped version of the value passed in as an argument so that it is suitable for embedding in the query portion of a URL.

Виновник экранированных данных в объекте Secret найден. Осталось только понять, почему же строка сначала была проэкранирована, а не расшифрована.

Тут придётся вспомнить, как именно argocd-vault-plugin устанавливается в кластер. Обратимся к официальной документации и найдём в ней ссылку на пример манифеста ConfigMap, который и объясняет происходящее волшебство:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  configManagementPlugins: |
    - name: argocd-vault-plugin
      generate:
        command: ["argocd-vault-plugin"]
        args: ["generate", "./"]

    - name: argocd-vault-plugin-helm
      generate:
        command: ["sh", "-c"]
        args: ['helm template "$ARGOCD_APP_NAME" -n "$ARGOCD_APP_NAMESPACE" . | argocd-vault-plugin generate -']

    # This lets you pass args to the Helm invocation as described here: https://argocd-vault-plugin.readthedocs.io/en/stable/usage/#with-helm
    # IMPORTANT: passing $helm_args effectively allows users to run arbitrary code in the Argo CD repo-server.
    # Only use this when the users are completely trusted. If possible, determine which Helm arguments are needed by 
    # your users and explicitly pass only those arguments.
    - name: argocd-vault-plugin-helm-with-args
      generate:
        command: ["sh", "-c"]
        args: ['helm template "$ARGOCD_APP_NAME" -n "$ARGOCD_APP_NAMESPACE" ${helm_args} . | argocd-vault-plugin generate -']

    # This lets you pass a values file as a string as described here:
    # https://argocd-vault-plugin.readthedocs.io/en/stable/usage/#with-helm
    - name: argocd-vault-plugin-helm-with-values
      generate:
        command: ["bash", "-c"]
        args: ['helm template "$ARGOCD_APP_NAME" -n "$ARGOCD_APP_NAMESPACE" -f <(echo "$ARGOCD_ENV_HELM_VALUES") . | argocd-vault-plugin generate -']

    - name: argocd-vault-plugin-kustomize
      generate:
        command: ["sh", "-c"]
        args: ["kustomize build . | argocd-vault-plugin generate -"]

Главное, что нужно тут заметить - сперва вызывается helm template, который рендерит шаблон, в том числе выполняя urlquery, и только после этого подменяются секреты. Указание секретов для плагина имеет строгий синтаксис, помните?

secret: <path:path/to/secret/in/vault#secret_key>

Но когда этот строгий синтаксис подвергается экранированию при рендере чарта, то плагин уже не в состоянии заменить значение. Вот и вся загадка.

Заключение

Конечно, подобных проблем можно было избежать, но история не терпит сослагательного наклонения, поэтому надеюсь, что моё небольшое исследование покажется кому-то полезным или, может быть, даже сэкономит несколько часов работы.

Я рад, что пришлось погрузиться в такие дебри, ведь на ошибках учимся. Делитесь своими кейсами подобного рода, будет интересно почитать.