Есть ли способ подключиться к неопубликованному сокету в бочке Kubernetes снаружи? - PullRequest
2 голосов
/ 28 января 2020

У меня есть незащищенный Postfix экземпляр в контейнере, который прослушивает порт 25. Этот порт не выставляется с помощью Service. Идея состоит в том, что только контейнер PHP, который работает внутри того же модуля, должен иметь возможность подключаться к Postfix, и нет необходимости в дополнительной конфигурации Postfix.

Есть ли способ для других процессов, которые работают в той же сети или кластере Kubernetes для подключения к этому скрытому порту?

Из того, что я знаю, только другие контейнеры в том же модуле могут подключаться к неэкспонированному порту через localhost.

Мне интересно с точки зрения безопасности.

PS Теперь я должен убедиться, что он имеет несколько уровней безопасности, но меня интересует только теоретически, если есть какой-то способ подключения к этому порту снаружи модуля.

Ответы [ 2 ]

1 голос
/ 29 января 2020

Из того, что я знаю, только другие контейнеры в том же модуле могут подключаться к неэкспонированному порту через localhost.

Не совсем. Как это реализовано, является деталью конкретного используемого времени выполнения контейнера.

... Меня интересует только теоретически, если есть какой-то способ подключения к этому порту снаружи модуля .

Итак, здесь мы go:)

Например, в GKE вы можете легко получить доступ к Pod из другого Pod , если вы знаете IP Target Pod .

Я использовал следующую настройку в GKE:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    run: fake-web
  name: fake-default-knp
spec:
  containers:
  - image: mendhak/http-https-echo
    imagePullPolicy: IfNotPresent
    name: fake-web

Файл Docker для этого изображения можно найти здесь . Он указывает EXPOSE 80 443 Итак, контейнер прослушивает эти 2 порта.

$kubectl exec fake-default-knp -- netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 :::443                  :::*                    LISTEN      1/node
tcp        0      0 :::80                   :::*                    LISTEN      1/node

У меня нет служб:

$kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   40d

и только 2 модуля.

$kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP
busybox-sleep-less               1/1     Running   3476       40d   10.52.1.6
fake-default-knp                 1/1     Running   0          13s   10.52.0.50  

И я могу подключиться к

$kubectl exec busybox-sleep-less -- telnet 10.52.0.50 80
Connected to 10.52.0.50
$kubectl exec busybox-sleep-less -- telnet 10.52.0.50 443
Connected to 10.52.0.50

Как видите, контейнер доступен на POD_IP:container_port из другого модуля (расположенного на другом узле)

PS> Стоит проверить «Межпроцессное взаимодействие (IP C)», если вы действительно хотели бы продолжать использовать незащищенный Postfix и предпочитаете избегать «несанкционированного доступа извне Pod». Это описано здесь .

Надеюсь, что это поможет!


Редактировать 30-янв-2020

Я решил немного поиграть с ним немного. Технически, вы можете достичь того, что вы хотите с помощью iptables. Вы должны специально принять все трафики c с localhost на порту 25 и DROP отовсюду.

что-то вроде:

cat iptab.txt 
# Generated by xtables-save v1.8.2 on Thu Jan 30 16:37:27 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -p 6 -m tcp --dport 80 -j ACCEPT
-A INPUT -p 6 -m tcp --dport 80 -j DROP
COMMIT

Я проверил это и не могу lnet на 80-м порту из любой точки, кроме той самой Pod. Обратите внимание, что мне пришлось запустить свой контейнер в привилегированном режиме, чтобы иметь возможность редактировать правила iptables непосредственно из Pod. Но это выходит за рамки первоначального вопроса. :)

0 голосов
/ 28 января 2020

Да, вы можете использовать kubectl port-forward для настройки туннеля непосредственно к нему в целях тестирования.

...