Migración de trust domain
Esta tarea muestra cómo migrar de un trust domain a otro sin cambiar la política de autorización.
En Istio 1.4, introducimos una feature alfa para soportar la trust domain migration para la política de autorización. Esto significa que si una
malla de Istio necesita cambiar su trust domain, la política de autorización no necesita ser cambiada manualmente.
En Istio, si un workload se está ejecutando en el namespace foo
con la cuenta de service bar
, y el trust domain del sistema es my-td
,
la identidad de dicho workload es spiffe://my-td/ns/foo/sa/bar
. Por defecto, el trust domain de la malla de Istio es cluster.local
,
a menos que lo especifique durante la instalación.
Antes de empezar
Antes de comenzar esta tarea, haga lo siguiente:
Lea los conceptos de autorización de Istio.
Instale Istio con un trust domain personalizado y mTLS habilitado.
$ istioctl install --set profile=demo --set meshConfig.trustDomain=old-td
Despliegue la muestra httpbin en el namespace
default
y la muestra curl en los namespacesdefault
ycurl-allow
:$ kubectl label namespace default istio-injection=enabled $ kubectl apply -f @samples/httpbin/httpbin.yaml@ $ kubectl apply -f @samples/curl/curl.yaml@ $ kubectl create namespace curl-allow $ kubectl label namespace curl-allow istio-injection=enabled $ kubectl apply -f @samples/curl/curl.yaml@ -n curl-allow
Aplique la política de autorización a continuación para denegar todas las solicitudes a
httpbin
excepto las decurl
en el namespacecurl-allow
.$ kubectl apply -f - <<EOF apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: service-httpbin.default.svc.cluster.local namespace: default spec: rules: - from: - source: principals: - old-td/ns/curl-allow/sa/curl to: - operation: methods: - GET selector: matchLabels: app: httpbin --- EOF
Tenga en cuenta que la política de autorización puede tardar decenas de segundos en propagarse a los sidecars.
Verifique que las solicitudes a
httpbin
desde:curl
en el namespacedefault
son denegadas.$ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 403
curl
en el namespacecurl-allow
son permitidas.$ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 200
Migrar trust domain sin alias de trust domain
Instale Istio con un nuevo trust domain.
$ istioctl install --set profile=demo --set meshConfig.trustDomain=new-td
Vuelva a desplegar istiod para que recoja los cambios del trust domain.
$ kubectl rollout restart deployment -n istio-system istiod
La malla de Istio ahora se está ejecutando con un nuevo trust domain,
new-td
.Vuelva a desplegar las applications
httpbin
ycurl
para que recojan los cambios del nuevo control plane de Istio.$ kubectl delete pod --all
$ kubectl delete pod --all -n curl-allow
Verifique que las solicitudes a
httpbin
desdecurl
en el namespacedefault
y en el namespacecurl-allow
son denegadas.$ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 403
$ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 403
Esto se debe a que especificamos una política de autorización que deniega todas las solicitudes a
httpbin
, excepto las de la identidadold-td/ns/curl-allow/sa/curl
, que es la antigua identidad de la applicationcurl
en el namespacecurl-allow
. Cuando migramos a un nuevo trust domain, es decir,new-td
, la identidad de esta applicationcurl
es ahoranew-td/ns/curl-allow/sa/curl
, que no es lo mismo queold-td/ns/curl-allow/sa/curl
. Por lo tanto, las solicitudes de la applicationcurl
en el namespacecurl-allow
ahttpbin
que antes estaban permitidas ahora están siendo denegadas. Antes de Istio 1.4, la única forma de hacer que esto funcionara era cambiar la política de autorización manualmente. En Istio 1.4, introducimos una forma sencilla, como se muestra a continuación.
Migrar trust domain con alias de trust domain
Instale Istio con un nuevo trust domain y alias de trust domain.
$ cat <<EOF > ./td-installation.yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: meshConfig: trustDomain: new-td trustDomainAliases: - old-td EOF $ istioctl install --set profile=demo -f td-installation.yaml -y
Sin cambiar la política de autorización, verifique que las solicitudes a
httpbin
desde:curl
en el namespacedefault
son denegadas.$ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 403
curl
en el namespacecurl-allow
son permitidas.$ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{\n}" 200
Mejores prácticas
A partir de Istio 1.4, al escribir la política de autorización, debe considerar usar el valor cluster.local
como la
parte del trust domain en la política. Por ejemplo, en lugar de old-td/ns/curl-allow/sa/curl
, debería ser cluster.local/ns/curl-allow/sa/curl
.
Tenga en cuenta que en este caso, cluster.local
no es el trust domain de la malla de Istio (el trust domain sigue siendo old-td
). Sin embargo,
en la política de autorización, cluster.local
es un puntero que apunta al trust domain actual, es decir, old-td
(y más tarde new-td
), así como a sus alias.
Al usar cluster.local
en la política de autorización, cuando migre a un nuevo trust domain, Istio detectará esto y tratará el nuevo trust domain
como el antiguo trust domain sin que tenga que incluir los alias.
Limpieza
$ kubectl delete authorizationpolicy service-httpbin.default.svc.cluster.local
$ kubectl delete deploy httpbin; kubectl delete service httpbin; kubectl delete serviceaccount httpbin
$ kubectl delete deploy curl; kubectl delete service curl; kubectl delete serviceaccount curl
$ istioctl uninstall --purge -y
$ kubectl delete namespace curl-allow istio-system
$ rm ./td-installation.yaml