Підключення сертифікатів ЦС

Це завдання показує, як адміністратори можуть налаштувати центр сертифікації (ЦС, certificate authority — CA) Istio з кореневим сертифікатом, сертифікат підпису та ключ.

Стандартно центр сертифікації Istio генерує самопідписний кореневий сертифікат і ключ та використовує їх для підпису сертифікатів робочого навантаження. Щоб захистити кореневий ключ CA, слід використовувати кореневий центр сертифікації, який працює на безпечній машині офлайн, і використовувати кореневий CA для видачі проміжних сертифікатів центрам сертифікації Istio, які працюють у кожному кластері. Центр сертифікації Istio може підписувати сертифікати робочого навантаження за допомогою вказаного адміністратором сертифіката та ключа, а також розповсюджувати вказаний адміністратором кореневий сертифікат до робочих навантажень як кореневий довірчий сертифікат.

Наступна схема демонструє рекомендовану ієрархію CA у мережі, що містить два кластери.

Ієрархія CA
Ієрархія CA

Це завдання демонструє, як згенерувати та підключити сертифікати та ключ для центру сертифікації Istio. Ці кроки можна повторити для забезпечення сертифікатами та ключами сертифікаційні центри Istio, що працюють у кожному кластері.

Підключення сертифікатів і ключа до кластера

  1. У кореневій теці пакета встановлення Istio створіть теку для зберігання сертифікатів та ключів:

    $ mkdir -p certs
    $ pushd certs
  2. Згенеруйте кореневий сертифікат і ключ:

    $ make -f ../tools/certs/Makefile.selfsigned.mk root-ca

    Це призведе до створення наступних файлів:

    • root-cert.pem: згенерований кореневий сертифікат
    • root-key.pem: згенерований кореневий ключ
    • root-ca.conf: конфігурація для openssl для генерації кореневого сертифіката
    • root-cert.csr: згенерований CSR для кореневого сертифіката
  3. Для кожного кластера створіть проміжний сертифікат і ключ для Istio CA. Нижче наведено приклад для cluster1:

    $ make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    Це призведе до створення наступних файлів у теці з назвою cluster1:

    • ca-cert.pem: згенеровані проміжні сертифікати
    • ca-key.pem: згенерований проміжний ключ
    • cert-chain.pem: згенерований ланцюжок сертифікатів, який використовується istiod
    • root-cert.pem: кореневий сертифікат

    Ви можете замінити cluster1 на рядок за вашим вибором. Наприклад, з аргументом cluster2-cacerts, ви можете створити сертифікати та ключ у теці з назвою cluster2.

    Якщо ви виконуєте ці дії на офлайн-машині, скопіюйте згенеровану теку на машину з доступом до кластерів.

  4. У кожному кластері створіть secret cacerts з усіма вхідними файлами ca-cert.pem, ca-key.pem, root-cert.pem і cert-chain.pem. Наприклад, для cluster1:

    $ kubectl create namespace istio-system
    $ kubectl create secret generic cacerts -n istio-system \
          --from-file=cluster1/ca-cert.pem \
          --from-file=cluster1/ca-key.pem \
          --from-file=cluster1/root-cert.pem \
          --from-file=cluster1/cert-chain.pem
  5. Повернутися до теки верхнього рівня встановлення Istio:

    $ popd

Розгортання Istio

  1. Розгорніть Istio за допомогою профілю demo.

    Центр сертифікації Istio зчитає сертифікати та ключ з файлів secret-mount.

    $ istioctl install --set profile=demo

Розгортання демонстраційних сервісів

  1. Розгорніть демонстраційні сервіси httpbin та curl.

    $ kubectl create ns foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/curl/curl.yaml) -n foo
  2. Розгорніть політику для робочих навантажень у просторі імен foo, щоб приймати лише взаємний TLS-трафік.

    $ kubectl apply -n foo -f - <<EOF
    apiVersion: security.istio.io/v1
    kind: PeerAuthentication
    metadata:
      name: "default"
    spec:
      mtls:
        mode: STRICT
    EOF

Перевірка сертифікатів

У цьому розділі ми перевіримо, що сертифікати робочого навантаження підписані тими сертифікатами, які були підключені до CA. Для цього необхідно, щоб на вашій машині було встановлено openssl.

  1. Почекайте 20 секунд, щоб політика mTLS набула чинності, перш ніж отримати ланцюжок сертифікатів для httpbin. Оскільки сертифікат CA, що використовується в цьому прикладі, є самопідписним, помилка verify error:num=19:self signed certificate in certificate chain, що повертається командою openssl, є очікуваною.

    $ sleep 20; kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -showcerts -connect httpbin.foo:8000 > httpbin-proxy-cert.txt
  2. Проаналізуйте сертифікати в ланцюжку сертифікатів.

    $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' httpbin-proxy-cert.txt > certs.pem
    $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem
  3. Переконайтеся, що кореневий сертифікат збігається з тим, який вказав адміністратор:

    $ openssl x509 -in certs/cluster1/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
    $ openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt
    $ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
    Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical
  4. Переконайтеся, що сертифікат ЦС збігається з сертифікатом, вказаним адміністратором:

    $ openssl x509 -in certs/cluster1/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
    $ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
    $ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
    Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical
  5. Перевірте ланцюжок сертифікатів від кореневого сертифіката до сертифіката робочого навантаження:

    $ openssl verify -CAfile <(cat certs/cluster1/ca-cert.pem certs/cluster1/root-cert.pem) ./proxy-cert-1.pem
    ./proxy-cert-1.pem: OK

Очищення

  • Видаліть сертифікати, ключі та проміжні файли з локального диска:

    $ rm -rf certs
  • Видаліть secret cacerts:

    $ kubectl delete secret cacerts -n istio-system
  • Видаліть політику автентифікації з простору імен foo:

    $ kubectl delete peerauthentication -n foo default
  • Видаліть демонстраційні застосунки curl та httpbin:

    $ kubectl delete -f samples/curl/curl.yaml -n foo
    $ kubectl delete -f samples/httpbin/httpbin.yaml -n foo
  • Видаліть Istio з кластера:

    $ istioctl uninstall --purge -y
  • Видалити простір імен foo та istio-system з кластера:

    $ kubectl delete ns foo istio-system
Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!