Https сертификаты и Kubernetes (EKS)

Question

Я хотел бы защитить свое веб-приложение, работающее на 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://service_name (НЕ 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? Должна ли эта конфигурация выполняться внутри контейнера или в конфигурациях служб?

Answer 1

Я провел немало исследований, и вот к чему я пришел.

Все мои экземпляры EKS EC2 работают в частных подсетях, что означает, что они недоступны извне. Да, по умолчанию Kubernetes не шифрует трафик между модулями, что означает, что хакер, получивший доступ к моему VPC (мог быть мошенником AWS, человеком, которому удается физически получить доступ к центрам обработки данных AWS, человеком, которому удалось получить доступ к моей учетной записи AWS). .) сможет прослушивать сетевой трафик. В то же время я чувствую, что в этом случае хакер получит доступ к гораздо большему! Если у него есть доступ к моей учетной записи AWS, он может загрузить, например, сертификат https. Если ему удастся войти в центр обработки данных AWS (с высокой степенью безопасности) и найти мой сервер - хорошо сравнить риск, с которым он должен пойти, и ценность ваших данных. Если ваши данные включают в себя данные кредитной карты / платежи или конфиденциальные личные данные (дата рождения, данные о состоянии здоровья ...), необходимо шифрование SSL. В любом случае, для обеспечения безопасности трафика существует 2 варианта.

1. Обновите весь исходный код модуля и добавьте туда сертификат. Требуется много обслуживания, если у вас много модулей, а срок действия сертификатов истекает через год.
2. Добавьте дополнительный «сетевой уровень», такой как https://istio.io/. Это добавит сложности вашему кластеру, а в случае EKS поддержка со стороны AWS будет «лучшим усилием». В идеале вы платите за поддержку Istio.

Для балансировщика нагрузки я решил добавить вход в кластер (Ngnix, Traefik ...) и настроить его с помощью https. Это очень важно, поскольку ELB находится в общедоступных подсетях.