Hashicorp Consul - Как сделать проверенный TLS из подов в кластере Kubernetes - PullRequest
Новая
       74

Hashicorp Consul - Как сделать проверенный TLS из подов в кластере Kubernetes

2 голосов
/ 26 мая 2020

Мне трудно понять сквозной TLS Consul. Для справки, я использую Consul в Kubernetes (через hashicorp / consul Helm chart). Только один центр обработки данных и кластер Kubernetes - никаких внешних сторон или проблем.

Я настроил свой файл переопределения values.yaml следующим образом: 

global:
  datacenter: sandbox

  gossipEncryption:
    secretName: "consul"
    secretKey: "CONSUL_GOSSIP_ENCRYPTION_KEY"

  tls:
    enabled: true
    httpsOnly: true
    enableAutoEncrypt: true
    serverAdditionalDNSSANs: ["'consul.service.consul'"]

server:
  replicas: 3
  bootstrapExpect: 3
  storage: 20Gi

dns:
  clusterIP: 172.20.53.53

ui:
  service:
    type: 'LoadBalancer'

syncCatalog:
  enabled: true

Все остальные значения по умолчанию из отправленного файла values.yaml .

Это работает, и журналы клиентов Consul предполагают, что все агенты подключаются с помощью TLS, с соответствующими сертификатами и ключами создается (как я понимаю) функцией Авто-шифрования Consul.

Я не понимаю, как инициировать HTTPS-соединение из приложения в Kubernetes, запущенном в Pod, на сервер Consul. Поскольку контейнер Pod (предположительно) не имеет сертификата Consul root CA в своем хранилище доверенных сертификатов, все вызовы HTTPS завершаются сбоем, как показано в примере wget ниже: 

# Connect to Pod:
laptop$> kubectl exec -it my-pod sh

# Attempt valid HTTPS connection:
my-pod$> wget -q -O - https://consul.service.consul:8501
Connecting to consul.service.consul:8501 (10.110.1.131:8501)
ssl_client: consul.service.consul: certificate verification failed: unable to get local issuer certificate
wget: error getting response: Connection reset by peer

# Retry, but ignore certificate validity issues:
my-pod$> wget --no-check-certificate -q -O - https://consul.service.consul:8501/v1/status/leader
"10.110.1.131:8300"

Как я Я должен был обеспечить сквозные (проверенные) HTTPS-соединения из моих приложений в Kubernetes с Consul, если контейнер не распознает сертификат как действительный? Я что-то не понимаю о распространении сертификатов?

Большое спасибо - Аарон

1 Ответ

0 голосов
/ 31 мая 2020

Решено с благодарностью Hashicorp на их форуме обсуждения Consul .

  • Создайте секрет Kubernetes с именем consul с ключом под названием CONSUL_GOSSIP_ENCRYPTION_KEY и соответствующее значение ключа шифрования.
    • Сгенерировать значение, используя consul keygen
  • Установите hashicorp / consul Helm chart с values-override.yaml, например, как показано ниже: 
global:
  datacenter: sandbox

  gossipEncryption:
    secretName: "consul"
    secretKey: "CONSUL_GOSSIP_ENCRYPTION_KEY"

  tls:
    enabled: true
    httpsOnly: true
    enableAutoEncrypt: true
    serverAdditionalDNSSANs: ["'consul.service.consul'"]

server:
  replicas: 3
  bootstrapExpect: 3
  storage: 20Gi

dns:
  clusterIP: 172.20.53.53

ui:
  service:
    type: 'LoadBalancer'

syncCatalog:
  enabled: true
  • Создайте пример Pod spe c для представления нашего приложения.
    • Убедитесь, что он устанавливает секрет сертификата CA сервера Consul.
    • Убедитесь, что контейнер Pod имеет HOST_IP , открытый как переменная среды. 
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: test-pod
spec:
  volumes:
  - name: consul-consul-ca-cert
    secret:
      secretName: consul-consul-ca-cert
  hostNetwork: false
  containers:
  - name: consul-test-pod
    image: alpine
    imagePullPolicy: IfNotPresent
    env:
    - name: HOST_IP
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP
    command: ["/bin/sh"]
    args: ["-c", "while true; do sleep 24h; done"]
    volumeMounts:
    - name: consul-consul-ca-cert
      mountPath: /consul/tls/ca
  • После создания Pod, kubectl exec в него и убедитесь, что установлены пакеты ca-Certific и curl (я используя Alpine Linux в этом примере).
    • ( curl исключительно для целей тестирования) 
#> apk update
#> apk add ca-certificates curl
  • Скопируйте установленный сертификат CA сервера Consul в / usr / local / share / ca-Certific / и выполните update-ca-certificates, чтобы добавить его в систему root хранилище CA. 
#> cp /consul/tls/ca/tls.crt /usr/local/share/ca-certificates/consul-server-ca.crt
#> update-ca-certificates  # might give a trivial warning - ignore it
  • Consul server теперь доступен (и доверяет) через HTTPS, как показано ниже: 
#> curl https://consul.service.consul:8501/v1/status/leader
## No TLS errors ##
  • Мы также хотим поговорить с Consul client (вместо сервера) через HTTPS по соображениям производительности.
    • Поскольку у клиента Consul есть собственный сертификат CA, нам нужно получить его с сервера.
    • Для этого требуется двоичный файл consul-k8s , поэтому нам нужно получить это. 
#> cd /usr/local/bin
#> wget https://releases.hashicorp.com/consul-k8s/0.15.0/consul-k8s_0.15.0_linux_amd64.zip  # (or whatever latest version is)
#> unzip consul-k8s_0.15.0_linux_amd64.zip
#> rm consul-k8s_0.15.0_linux_amd64.zip
  • Получите Consul client CA сертификат и установите его через update-ca-certificates: 
#> consul-k8s get-consul-client-ca -server-addr consul.service.consul -server-port 8501 -output-file /usr/local/share/ca-certificates/consul-client-ca.crt
#> update-ca-certificates  # might give a trivial warning - ignore it
  • Consul client теперь доступен (и доверяет) через HTTPS, как показано ниже: 
#> curl https://$HOST_IP:8501/v1/status/leader
## No TLS errors ##
  • Мы также можем получить доступ к Consul КВ сервис от клиента без проблем: 
#> curl https://$HOST_IP:8501/v1/kv/foo/bar/baz
## No TLS errors ##

Естественно, все вышеперечисленное должно быть автоматизировано исполнителем. Эти действия вручную предназначены исключительно для демонстрационных целей.

...