Комментарии 6
Спасибо, познавательно!
Схема получается следующей: на старте приложения argocd-repo-server, initContainer скачивает требуемый плагин.
не очень хорошая схема - стоит упомянуть, что она вносит неопределенность в процесс выполнения (может плагин скачается, может не скачается + время на скачивание), плюс emptydir в кластере может быть административно запрещен (ибо нефиг на самом деле).
Что более интересно - увидеть преимущества конкретной описанный схемы перед, скажем, альтернативами в виде Flux + Sops или вообще Sealed secrets.
По настоящей же статье возник такой вопрос - как обеспечивается изоляция секретов? Чтобы приложение А, устанавливаемое через арго, не могло посмотреть в секрет, который нужен только приложению Б (тоже устанавливаемое через арго)?
Пожалуй, ответи стоит разделить на пункты:
Оценивать схему можно с учётом её плюсов и минусов с учётом рабочих условий. Можно обновлять официальный образ argocd-repo-server, и делать это при каждом обновлении ArgoCD, что добавляет накладные расходы на пересборку образа. Скачивание плагина можно запроксировать через какой-нибудь artifactory или nexus, чтобы всегда была возможность подтянуть из кеша, даже если github стал недоступен. При наличии ограничения emtyDir, можно прибегнуть к хранению плагина в persistent volume, либо всё же выбрать предыдущий вариант.
Альтернативу Flux + SOPS в рамках данной статьи рассматривать не получится, т.к выбор будет между ArgoCD и FluxCD. Но можно рассмотреть SOPS в качестве альтернативы AVP. Также необходимо подключить плагин, либо через пересборку образа, либо подключения через initContainer. Вариант с SOPS выглядит даже чуточку привлекательнее, т.к. не обязательно требуется внешний источник секретов, и есть варианты настроек. А Sealed secrets вообще особняком стоит как отдельное приложение, что в некоторой степени ещё более выигрышная схема. У всех решений есть свои нюансы. Взвешивая плюсы и минусы, на мой взгляд, при минимальных требованиях, проще реализовать схему с хранением секретов в Vault.
По поводу изоляции можно отметить следующее: в ArgoCD принадлежность ресурсов к Application определяется меткой по типу:
app.kubernetes.io/instance: my-app-my-ns-my-proj, и один и тот же ресурс может принадлежать только одному приложению, в противном случае будет вечный out of sync, и конкурентная борьба за ресурс. В случае из статьи, принадлежность относится только к приложению app-of-secrets, т.е. сам секрет в других приложениях можно подключать только как extraSecret. И в ArgoCD Application можно использовать только один source для Application, т.е это либо хелм, либо плагин, либо иной вариант. Если хотите разные Application для создания Secret, как вариант — раздельное хранение самих манифестов Secret.
спасибо
По поводу изоляции можно отметить следующее: в ArgoCD принадлежность ресурсов к Application определяется меткой по типу:
app.kubernetes.io/instance: my-app-my-ns-my-proj, и один и тот же ресурс может принадлежать только одному приложению, в противном случае будет вечный out of sync, и конкурентная борьба за ресурс. В случае из статьи, принадлежность относится только к приложению app-of-secrets, т.е. сам секрет в других приложениях можно подключать только как extraSecret. И в ArgoCD Application можно использовать только один source для Application, т.е это либо хелм, либо плагин, либо иной вариант. Если хотите разные Application для создания Secret, как вариант — раздельное хранение самих манифестов Secret.
боюсь, что мы друг друга не поняли ) Предположим, что есть кластер. В нем есть разные ns. Каждая команда пользователей имеет доступ к конкретному ns. По сути - мультитенантное окружение. Хотим разделять секреты. Какие варианты можете предложить именно в парадигме АргоСД? В external-secrets https://external-secrets.io/guides-multi-tenancy/ очень хорошо разные подходы...
Вы правы, действительно о разном) В рамках плагина такого подхода реализовать не получится. Подобный сценарий можно попробовать реализовать в рамках настройки доступа к проектам созданных в ArgoCD. Пример настройки declarative-setup/#projects
Сама схема звучит избыточно, и скорее будет правильнее использовать отдельный инструмент для multitenancy
Мне argocd-vault-plugin показался слишком неудобным в использовании. Более красивый, как по мне, подход: https://external-secrets.io/
Управление секретами в ArgoCD при помощи argocd-vault-plugin с Kubernetes auth