Как отключить небезопасное одобрение kubectl для kube apiserver

Я пытаюсь сделать свой главный сервер-API более безопасным, чтобы не пропускать запросы, отличные от https.

Пример конфигурации:

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    server: https://ip:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED

Которая работает, пока я использую правильные центры сертификации.

Моя проблема в том, что он также работает, если я удаляю CA или у меня ошибочно устанавливаются CA и я просто использую флаг - insecure-skip-tls-verify .

Как я могу заставить сервер разрешить https-соединения вместо http в Server-API?

Я также отключил анонимные запросы Анонимные запросы , но я все еще вижу, что запросы могут проходить.

0
задан 10 December 2020 в 15:01
1 ответ

Моя проблема в том, что это также работает, если я удаляю центры сертификации или у меня есть неправильные центры сертификации, и я просто применяю флаг --insecure-skip-tls-verify.

Использование --insecure-skip-tls-verify крайне НЕ РЕКОМЕНДУЕТСЯ в рабочей среде. Его можно использовать, когда вы хотите сделать некоторые локальные тесты или для целей обучения.

В документации Kubectl есть информация:

--insecure-skip-tls-verify

If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure

Итак, если этот флаг будет установлен как истина, он всегда будет пропускать сертификаты, а идентификация сервера вообще не проверяется. Это похоже на curl -k

-k, --insecure
              (TLS) By default, every SSL connection curl makes is verified to
              The  server  connection  is verified by making sure the server's
              interface name, IP address or host name.

Вы можете защитить свой кластер разными способами, но это зависит от сценария. Тем не менее, существуют некоторые основные порты и IP-адреса серверов API:

Использовать SecurePort

По умолчанию сервер API Kubernetes обслуживает HTTP на двух портах:

  1. порт localhost. :
  • предназначен для тестирования и начальной загрузки, а также для других компонентов мастер-узла (планировщик, контроллер-менеджер) для взаимодействия с API
  • без TLS
  • Отключите небезопасные http-соединения: по умолчанию используется порт 8080, измените его с помощью флага --insecure-port.(Его можно отключить с помощью --insecure-port=0)
  • IP-адрес по умолчанию localhost, измените флаг --insecure-bind-address . (Удалить --insecure-bind-address)
  • запрос обходит модули аутентификации и авторизации.
  • запрос обрабатывается модулем(ами) управления доступом.
  • защищено необходимостью доступа к хосту
  1. Безопасный порт:
  • используйте, когда это возможно Включить безопасный порт:
  • использует TLS. Установите сертификат с флагом --tls-cert-file и ключ с флагом --tls-private-key-file.
  • по умолчанию используется порт 6443, измените его с помощью флага --secure-port.
  • IP-адрес по умолчанию — первый нелокальный сетевой интерфейс, изменить с помощью флага --bind-address.
  • запрос обрабатывается модулями аутентификации и авторизации.
  • Запрос обрабатывается модулем(ами) управления доступом.
  • Запускаются модули аутентификации и авторизации.

Ограничить доступ к API. Это означает, что вы должны разрешать доступ к вашему API только с определенного IP-адреса или определенного диапазона IP-адресов (авторизованных сетей). Он не должен быть доступен извне. Для этого можно использовать правила брандмауэра или сетевую политику.

Отключите анонимные запросы, что вы уже сделали.

Вы можете посмотреть --insecure-port=0, однако в более новых версиях он должен быть объявлен устаревшим.

В качестве дополнительной информации советую почитать Kubernetes The Hard Way, особенно 3 главы: Инициализация вычислительных ресурсов, Инициализация ЦС и создание сертификатов TLS, Генерирование файлов конфигурации Kubernetes для аутентификации. Вы можете найти там несколько лучших практик.

Очень хорошее объяснение флагов Kube API-server вы можете найти в этой статье

Полезные ссылки о безопасности кластера:

Основы обеспечения безопасности кластеров Kubernetes – Как защитить kube-apiserver

Управление доступом к API Kubernetes

Рекомендации по безопасности Kubernetes

Kubernetes Security 101: риски и 29 рекомендаций

Управление доступом к API Kubernetes

Доступ к кластерам

1
ответ дан 23 December 2020 в 09:09

Теги

Похожие вопросы