Comments 7
А чем https://strimzi.io/ то не устроил ? Можно к его crd свой контроллер добавить и не пилить всё с нуля
Приветствую
Strimzi смотрели, давно правда. Там основной проблемой было, что ACL были склеены с сущностью KafkaUser, что, в общем-то, логично.
Я выше писал, что основной целью было дать возможность разработке полностью управлять сущностями, которые
относятся к их проекту. А в такой конфигурации нужен был бы кто-то, кто имеет доступ к CR соседей, или вообще ко всем. На наш общий чарт и схему деплоя это, соответственно, не ложилось. Контроллер бы(даже целых 2) пришлось бы свой писать, как вы и сказали. Ну а поддерживать форк проекта на джаве с этими контроллерами желания особо не было.
Свой оператор на operator-sdk написать было проще, да и поддерживать в дальнейшем тоже.
А как вы управляете пользователями? На сколько я знаю, это можно сделать либо через запуск консольных команд, либо через java client. Ни Python клиент, ни любой другой, на базе librdkafka, этого не умеют.
Интересное решение, спасибо. Подскажите, а вы креденшелсы в гите храните нешифрованными? При использовании того же SealedSecrets можно было бы добавить в манифест User дополнительную конфигурацию вроде такой:
spec:
user: pupkin
password: pupkin
existingSecret:
name: secret_name
userKey: username
passwordKey: passwordТогда values-файл для разработчиков мог бы выглядеть как-то так:
Kafka:
Auth:
User: encrypted_user
Password: encrypted_pass
ExistingSecret: secret_name # если определено, то Auth.User и Auth.Password игнорируются
Topics:
...По аналогии с Helm-чартами от Bitnami
Креды шифруем через SOPS https://github.com/mozilla/sops
Выглядит в репозитории это вот так примерно:
Kafka:
User: ENC[AES256_GCM,data:VxCWb+K/PdAe5mL4HhzN,iv:qm9Ju0bVLuzctsm5x1XjFvhBbWPkXovz+SFou3ot7MU=,tag:j367spKx0iafJmQGgpr0FQ==,type:str]
Password: ENC[AES256_GCM,data:pDkq2ZDGTyJ48jqYH7PAyt2OJ5A=,iv:nlVk0eRUPO8rTOmtZIKPqaaTa5TJMPUIK+FpW0RAw/8=,tag:CE1UcOp1cfSk7+vLS03lgQ==,type:str]Идея с инжектом в спеку полей из секрета была, но решили отказаться от нее по нескольким причинам:
1) API Kafka.User и так скрыто от разработчиков с помощью RBAC, так что расшифрованный секрет и CR User, по сути, представляют из себя одно и то же
2) В будущем планировали перейти на аутентификацию серт TLS серты от Vault.
За замечание спасибо, может и реализуем когда-то дополнительную поддержку.
Я так понимаю оператор не open-source?
Управляем пользователями и топиками Apache Kafka с помощью оператора Kubernetes