Подскажите с точки зрения ИБ, есть ли какие-то ограничения при

изоляции кастомных ресурсов (CRDs) в кластере с несколькими юзерами (если я не хочу чтобы они знали о кастомных ресурсах друг друга) ?

в CRD есть scope, он может namespased быть а может cluster

не понял вопрос

Почему тогда здесь фолс? /experiment1$ kubectl api-resources --namespaced=false NAME SHORTNAMES APIVERSION NAMESPACED KIND customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition

Сам по себе CRD естественно cluster scope - по другому и быть не может. Но тебе CRD нужны чтобы регистрировать кастомные ресурсы, эти костомные ресурсы могут быть в разных scope, это ты указываешь уже в самом CRD

Правильно ли я понимаю что мы изолируем сами ресурсы, а не их CRD. Но в таком случае тенанты могут получить доступ к CRD(так как оно не namespaced) и узнать какие ресурсы есть у других тенантов, не имея к ним доступа?

это не является проблемой

Ну по аналогии с другими ресурсами. Ты же не можешь скрыть тот факт, что у тебя в кластере существует ресурс типа Deployment? А он тоже namespaced. Какие типы ресурсов существуют в кластере нет смысла скрывать

Если я все правильно понял, то вы пытаетесь решить данную задачу/проблему, которую я описывал вот здесь https://t.me/k8security/52 Так можете на моем канале сделать поиск по словам "CRD", "RBAC" и "Multi-Tenancy" - думаю это поможет вашей работе.

> Так, например, можно знать какие порты точно слушаются сторонним решением А вот тут подробней. Как по спеке CRD или /apis можно узнать какие порты слушает стороннее решение ? (оператор имеется в виду?) Операторы которые обслуживают CRD, в целом не обязаны какие-то порты слушать, во вторых в спеке CRD нигде не указано какие порты слушают операторы, что их обслуживают, ну и в третьих сетевые политики же есть, лучше ограничить сетевыми политиками namespace где стоит оператор

1. Я не сторонник скрывать CRD. Это путь в security through obscurity. 2. Да - я за механизмы, которые предназначены для разграничения доступа: NetworkPolicy, RBAC и т.д. 3. Так по Custom Resource можно понять, что за оператор используется и какую технологию/решение он обслуживает. И вот у нее уже будут дефолтные порты и т.д. Но помимо этого есть решения, которые с собой еще тянут свой UI, на котором нет пароля или он дефолтный или его можно перебрать. Также по набору ресурсов можно понять в managed кластере ты находишься или нет и в каком именно (GKE, AKS, EKS) – там metadata-api и т.д.

Все же давайте подробней рассмотрим. Как конкретно выяснить по CRD, что за оператор его использует, и установлен ли он вообще, где установлен внутри кластера или снаружи? Я просто не представляю как это по CRD можно выяснить, не могли бы вы подробней это расписать? Я вот смотрю на CRD операторов в моем кластере, и не вижу никаких упоминаний, о том, где эти операторы работают, работают ли они вообще или в целом установлены ли они. Это просто спека с описаниеями полей объекта

Да, действительно не факт что они работают, но сканить сеть можно не по всему диапазону портов, а по уже небольшому списку.

по какому списку? Откуда взять список? Какие порты имеются в виду?