Сертификаты HTTPS и Kubernetes (EKS)
Я хочу защитить свое веб-приложение, работающее в Kubernetes (EKS). Все узлы, подключенные к кластеру, работают в частных подсетях.
У меня есть одна интерфейсная служба и дюжина внутренних служб.
Интерфейсная служба - это модуль, на котором запущен контейнер, работающий на порту 80. Он настроен для подключения к ELB, который принимает трафик только от 443 с сертификатом https.
apiVersion: v1
kind: Service
metadata:
name: service_name
labels:
app: service_name
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: xxxxxxxxxx
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
ports:
- port: 443 # Exposed port
targetPort: 80 # Container port
selector:
app: service_name
type: LoadBalancer
Внутренние службы - это модули, на которых работают контейнеры, также работающие на порту 80. Ни один из них не был настроен для доступа извне кластера. Внутренние службы взаимодействуют друг с другом, указывая на http: // имя_службы (НЕ https), поскольку я настроил их с помощью этого шаблона:
apiVersion: v1
kind: Service
metadata:
name: service_name
spec:
ports:
- port: 80 # Exposed port
targetPort: 80 # Container port
selector:
app: service_name
Все работает, но достаточно ли этого?
Должны ли внешние / внутренние контейнеры также использовать сертификат / 443 с подстановочным сертификатом https? Должна ли эта конфигурация выполняться внутри контейнера или в конфигурациях служб?
Ответы 1
Я провел довольно много исследований и вот к чему пришел.
Все мои экземпляры EKS EC2 работают в частных подсетях, что означает, что они недоступны извне. Да, по умолчанию Kubernetes не шифрует трафик между модулями, что означает, что хакер, получивший доступ к моему VPC (может быть мошенником-инженером AWS, кто-то, кому удается получить физический доступ к центрам обработки данных AWS, кто-то, кому удалось получить доступ к моей учетной записи AWS ... .) сможет прослушивать сетевой трафик. В то же время я чувствую, что в этом случае хакер получит доступ к гораздо большему! Если у него есть доступ к моей учетной записи AWS, он может, например, сам загрузить сертификат https. Если ему удастся зайти в центр обработки данных AWS (с высокой степенью защиты) и найти мой сервер - хорошо сравнить риск, который он должен принять, с ценностью ваших данных. Если ваши данные включают кредитную карту / платежи или конфиденциальные личные данные (дата рождения, сведения о здоровье ...), шифрование SSL является обязательным. В любом случае, для защиты трафика подов есть 2 варианта.
- Обновите весь исходный код модуля и добавьте туда сертификат. Если у вас много подов, он требует большого обслуживания, а срок действия сертификатов истекает раз в два года.
- Добавьте дополнительный «сетевой уровень», например https://istio.io/. Это усложнит ваш кластер, и в случае EKS поддержка AWS будет «максимальным усилием». В идеале вы должны заплатить за поддержку Istio.
Для балансировщика нагрузки я решил добавить вход в кластер (Ngnix, Traefik ...) и настроить его с помощью https. Это важно, поскольку ELB находится в общедоступных подсетях.