GG
если порт секурный - позволю себе догадаться, что тогда этот контроль не так критичен ?
Size: a a a
2020 December 03
AL
Ммм а зачем вообще доступ к порту шедулера? Есть вообще понимание какие такие cli/web ходят к нему
IR
мне нет. вопрос к проверкам бенчмарка. почему он для секьюрного порта тоже требует доступость только с локалхоста?
AK
Ммм а зачем вообще доступ к порту шедулера? Есть вообще понимание какие такие cli/web ходят к нему
Метрики.
GG
мне нет. вопрос к проверкам бенчмарка. почему он для секьюрного порта тоже требует доступость только с локалхоста?
где ты там такое увидел
IR
Ммм а зачем вообще доступ к порту шедулера? Есть вообще понимание какие такие cli/web ходят к нему
у меня такой же вопрос. кому надо напрямую к шедуллеру обращаться и что она хостит кроме хелсчека
GG
Метрики.
Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. (#93570, liggitt) [SIG API Machinery, Apps and Cluster Lifecycle]
???
???
DS
у меня такой же вопрос. кому надо напрямую к шедуллеру обращаться и что она хостит кроме хелсчека
метрики
AK
Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. (#93570, liggitt) [SIG API Machinery, Apps and Cluster Lifecycle]
???
???
А, вы про другой порт. Надобно сначала полный контекст дискуссии читать.
IR
где ты там такое увидел
вот отчтет от проверки kube-bench-ем
[FAIL] 1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
1.4.2 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml
on the master node and ensure the correct value for the --bind-address parameter
Он не првоеряет секьюрный там порт или нет. Он проверяет именно публичность интерфейса.
[FAIL] 1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
1.4.2 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml
on the master node and ensure the correct value for the --bind-address parameter
Он не првоеряет секьюрный там порт или нет. Он проверяет именно публичность интерфейса.
GG
ну, правильно, куббенч кривой
GG
я пытался им танзу проверить - там бред, а не отчет
IR
настроить скип - без проблем. С ИБ договоернность есть. Принципиально просто интересно.
GG
интересно, есть отчет гуглового контрол плейна
IR
и да у них этот тест PASS, то есть они ставят на 127.0.0.1
ИК
всем привет!
подскажите, пожалуйста, кто может потреблять API ендпоинтов, которые выставляют наружу sheduller и controller-manger?
Не могу нигде в доках найти конкретных примеров.
Вопрос возник в связи с тем, что хотим адаптировать кластер к некоторым проверкам CIS Benchmark-а. В нем есть пункт требующий чтобы флаг --bind-adress sheduller-а и controller-manger-а указывал на 127.0.0.1 вместо 0.0.0.0. В таком случае их API станет недоступно снаружи ноды. При этом в офф доках кубера по этому поводу сказано The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. Но что это за CLI/web clients - никакого пояснения.
Кластер при этом вроде работает, но уверенности в том, что позже не всплывут проблемы нет =).
Подскажите, кто пользуется в итоге этими API? =)
подскажите, пожалуйста, кто может потреблять API ендпоинтов, которые выставляют наружу sheduller и controller-manger?
Не могу нигде в доках найти конкретных примеров.
Вопрос возник в связи с тем, что хотим адаптировать кластер к некоторым проверкам CIS Benchmark-а. В нем есть пункт требующий чтобы флаг --bind-adress sheduller-а и controller-manger-а указывал на 127.0.0.1 вместо 0.0.0.0. В таком случае их API станет недоступно снаружи ноды. При этом в офф доках кубера по этому поводу сказано The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. Но что это за CLI/web clients - никакого пояснения.
Кластер при этом вроде работает, но уверенности в том, что позже не всплывут проблемы нет =).
Подскажите, кто пользуется в итоге этими API? =)
IR
хме. это значит кубспрей по умолчанию 0.0.0.0 ставит
DS
вот отчтет от проверки kube-bench-ем
[FAIL] 1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
1.4.2 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml
on the master node and ensure the correct value for the --bind-address parameter
Он не првоеряет секьюрный там порт или нет. Он проверяет именно публичность интерфейса.
[FAIL] 1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
1.4.2 Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml
on the master node and ensure the correct value for the --bind-address parameter
Он не првоеряет секьюрный там порт или нет. Он проверяет именно публичность интерфейса.
а как он кстати проверяет публичность порта? У меня например снаружи все прикрыто, внутри кластера netpol. Но внутри kube-system и для namespace мониторинга порт вполне может быть открыт