Я установил контейнер freeradius в кластере Kubernetes. По умолчанию freeradius не регистрирует попытки аутентификации или пароли в виде обычного текста, однако, если служба запускается с аргументом «-X» (режим отладки), она переопределяет конфигурацию по умолчанию и записывает ВСЕ в STDOUT. Я попытался не указывать этот аргумент в файле развертывания, но затем контейнер вылетает при запуске.
Есть ли способ запустить freeradius в контейнере, чтобы он не создавал эти журналы в первую очередь, или настроить развертывание так, чтобы к этим журналам нельзя было получить доступ?
Итак, оказалось, что был совершенно другой способ достичь моей цели, чем я ожидал. Мне удалось запустить контейнер freeradius без режима отладки, создав монтируемые тома EmptyDir для / var / run / freeradius и / var / log / freeradius, чтобы эти каталоги были доступны для записи (не знаю, почему / var / run / freeradius не 'не нужно быть доступным для записи в режиме отладки, ну да ладно), тогда для команды укажите следующую строку:
command: ["/bin/bash","-c","freeradius && tail -F /var/log/freeradius/radius.log"]
В основном это запускает freeradius, затем считывает журнал в STDOUT в реальном времени, обновляя его по мере записи новых строк в файл журнала.
Если вы ссылаетесь на журналы как на подресурс модуля, вы можете управлять им с помощью роли RBAC.
Чтобы представить это в роли RBAC, используйте косую черту для разделения ресурса и подресурса. Чтобы позволить субъекту читать как модули, так и журналы модулей, вы должны написать:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
Следовательно, чтобы ограничить доступ к журналам модуля, вам просто нужно НЕ включить "pods / log" в список ресурсов
Также имейте в виду, что правила в kubernetes RBAC являются чисто аддитивными, поэтому вам нужно будет перечислить все доступные ресурсы, иначе вы также не сможете получить к ним доступ.
Когда роль будет создана, вам нужно будет связать ее со своей учетной записью пользователя или службы в RoleBinding
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-logs-reader-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-logs-reader
subjects:
- kind: User
name: "john_calder@dude.com"
apiGroup: rbac.authorization.k8s.io