Обновить

Зачем мы сделали собственный контроллер для копирования секретов в Kubernetes

Время на прочтение13 мин
Количество просмотров8K
Всего голосов 18: ↑18 и ↓0+18
Комментарии11

Комментарии 11

  1. Про kubed вы неправильно написали "т.к. он полагается на лейблы, которые нужно проставить как на сами Secret или ConfigMap, так и на неймспейсы, в которые их нужно скопировать.", он может синхронизировать в любые НС без того чтобы давать аннотацию неймспейсам. Нужно только для секрета указать аннотацию, обычно нет проблем указать аннотацию ресурсы которым управляете вы сами.

    If a ConfigMap or a Secret has the annotation kubed.appscode.com/sync: "", Kubed will create a copy of that ConfigMap/Secret in all existing namespaces. Kubed will also create this ConfigMap/Secret, when you create a new namespace.

    Так же он может и между кластерами, но я не пробовал

  2. Для получения секрета из волта или других мест есть https://external-secrets.io/

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

  1. Да, я согласен, что в kubed есть возможность синхронизировать secret или configmap по всем неймспейсам сразу. Но это не подходит для нас. Для нас важно было копировать TLS-сертификат между неймспейсами "текущего" проекта. То есть, например, есть проект A и он раскладывается по веткам на домены main.projectA.example.com, feature-1.projectA.example.com, feature-2.projectA.example.com и т.д. Сертификат для *.projectA.example.com должен быть выпущен в единственном экземпляре (мы условились что будем это делать для ветки main) и в остальные фича-бранчи сертификат должен быть скопирован. А каждая фича-бранч раскладывается в отдельном неймспейса, поэтому нужно уметь указать в какие нс копировать. Ну и нам этот сертификат не нужен, например в неймспейсах для проекта B. Поэтому в общем единственный возможный сценарий использования kubed - это прослатвлять лейблы на нс, а это затруднительно для нас было.

  2. Спасибо за ссылку!

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

Чем не подошел Kustomize?

Можете пояснить вопрос? Где именно не подошел kustomize?

Не рассматривали, спасибо за ссылку. Правда не до конца понимаю, как с помощью kyverno в данном случае решить наш сценарий - чтобы Secret копировался только в нужные неймспейсы, а не во все?

У меня так - создается ns, вешается лейбл на него, kyverno переносит секрет

Hidden text
  - name: sync-pullsecret
    match:
      any:
      - resources:
          kinds:
          - Namespace
          selector:
            matchLabels:
              pullsecret-rollout: "true"
    generate:
      kind: Secret
      name: reg-pullsecret
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      clone:
        namespace: default
        name: reg-pullsecret

Получается нужно все равно вешать лейблы на неймспейсы? Это нас как раз не устраивало в том же kubed - хотелось просто описать регулярку, под которую должны попадать нс-ы, чтоб сикрет в них прилетал.

Нет. Kyverno поддерживает вайлдкарды. match: можно описать вот так:

    match:
      any:
      - resources:
          kinds:
          - Namespace
          names:
          - "foo-feature-*"

Вообще Kyverno замечательный комбайн, много всего с ним можно сделать и много вещей по отдельности замещает. Рекомендую.

Я просто оставлю это здесь

https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-wildcard-certificates

Так мы ведь и выписываем wildcard сертификаты. В статье описывается подход как скопировать выписанный сертификат между неймспейсами, где он нужен.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
kts.tech
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия