Підключення сертифікатів ЦС
Це завдання показує, як адміністратори можуть налаштувати центр сертифікації (ЦС, certificate authority — CA) Istio з кореневим сертифікатом, сертифікат підпису та ключ.
Стандартно центр сертифікації Istio генерує самопідписний кореневий сертифікат і ключ та використовує їх для підпису сертифікатів робочого навантаження. Щоб захистити кореневий ключ CA, слід використовувати кореневий центр сертифікації, який працює на безпечній машині офлайн, і використовувати кореневий CA для видачі проміжних сертифікатів центрам сертифікації Istio, які працюють у кожному кластері. Центр сертифікації Istio може підписувати сертифікати робочого навантаження за допомогою вказаного адміністратором сертифіката та ключа, а також розповсюджувати вказаний адміністратором кореневий сертифікат до робочих навантажень як кореневий довірчий сертифікат.
Наступна схема демонструє рекомендовану ієрархію CA у мережі, що містить два кластери.
Це завдання демонструє, як згенерувати та підключити сертифікати та ключ для центру сертифікації Istio. Ці кроки можна повторити для забезпечення сертифікатами та ключами сертифікаційні центри Istio, що працюють у кожному кластері.
Підключення сертифікатів і ключа до кластера
У кореневій теці пакета встановлення Istio створіть теку для зберігання сертифікатів та ключів:
$ mkdir -p certs $ pushd certsЗгенеруйте кореневий сертифікат і ключ:
$ make -f ../tools/certs/Makefile.selfsigned.mk root-caЦе призведе до створення наступних файлів:
root-cert.pem: згенерований кореневий сертифікатroot-key.pem: згенерований кореневий ключroot-ca.conf: конфігурація дляopensslдля генерації кореневого сертифікатаroot-cert.csr: згенерований CSR для кореневого сертифіката
Для кожного кластера створіть проміжний сертифікат і ключ для Istio CA. Нижче наведено приклад для
cluster1:$ make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacertsЦе призведе до створення наступних файлів у теці з назвою
cluster1:ca-cert.pem: згенеровані проміжні сертифікатиca-key.pem: згенерований проміжний ключcert-chain.pem: згенерований ланцюжок сертифікатів, який використовується istiodroot-cert.pem: кореневий сертифікат
Ви можете замінити
cluster1на рядок за вашим вибором. Наприклад, з аргументомcluster2-cacerts, ви можете створити сертифікати та ключ у теці з назвоюcluster2.Якщо ви виконуєте ці дії на офлайн-машині, скопіюйте згенеровану теку на машину з доступом до кластерів.
У кожному кластері створіть 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Повернутися до теки верхнього рівня встановлення Istio:
$ popd
Розгортання Istio
Розгорніть Istio за допомогою профілю
demo.Центр сертифікації Istio зчитає сертифікати та ключ з файлів secret-mount.
$ istioctl install --set profile=demo
Розгортання демонстраційних сервісів
Розгорніть демонстраційні сервіси
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Розгорніть політику для робочих навантажень у просторі імен
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.
Почекайте 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Проаналізуйте сертифікати в ланцюжку сертифікатів.
$ 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Переконайтеся, що кореневий сертифікат збігається з тим, який вказав адміністратор:
$ 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Переконайтеся, що сертифікат ЦС збігається з сертифікатом, вказаним адміністратором:
$ 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Перевірте ланцюжок сертифікатів від кореневого сертифіката до сертифіката робочого навантаження:
$ 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