Authorization Policy Trust Domain Migration
This task shows you how to migrate from one trust domain to another without changing authorization policy.
In Istio 1.4, we introduce an alpha feature to support trust domain migration for authorization policy. This means if anIstio mesh needs to change its trust domain, the authorization policy doesn’t need to be changed manually.In Istio, if a workload is running in namespace foo
with the service account bar
, and the trust domain of the system is my-td
,the identity of said workload is spiffe://my-td/ns/foo/sa/bar
. By default, the Istio mesh trust domain is cluster.local
,unless you specify it during the installation.
Before you begin
Read the authorization concept guide.
Install Istio with a custom trust domain and mutual TLS enabled.
$ cat <<EOF > ./td-installation.yaml
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
values:
global:
controlPlaneSecurityEnabled: false
mtls:
enabled: true
trustDomain: old-td
EOF
$ istioctl manifest apply --set profile=demo -f td-installation.yaml
- Deploy the httpbin sample in the
default
namespaceand the sleep sample in thedefault
andsleep-allow
namespaces:
$ kubectl label namespace default istio-injection=enabled
$ kubectl apply -f @samples/httpbin/httpbin.yaml@
$ kubectl apply -f @samples/sleep/sleep.yaml@
$ kubectl create namespace sleep-allow
$ kubectl label namespace sleep-allow istio-injection=enabled
$ kubectl apply -f @samples/sleep/sleep.yaml@ -n sleep-allow
- Apply the authorization policy below to deny all requests to
httpbin
except fromsleep
in thesleep-allow
namespace.
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: service-httpbin.default.svc.cluster.local
namespace: default
spec:
rules:
- from:
- source:
principals:
- old-td/ns/sleep-allow/sa/sleep
to:
- operation:
methods:
- GET
selector:
matchLabels:
app: httpbin
---
EOF
Notice that it may take tens of seconds for the authorization policy to be propagated to the sidecars.
Verify that requests to
httpbin
from:sleep
in thedefault
namespace are denied.
$ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
403
sleep
in thesleep-allow
namespace are allowed.
$ kubectl exec $(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
200
Migrate trust domain without trust domain aliases
- Install Istio with a new trust domain.
$ cat <<EOF > ./td-installation.yaml
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
values:
global:
controlPlaneSecurityEnabled: false
mtls:
enabled: true
trustDomain: new-td
EOF
$ istioctl manifest apply --set profile=demo -f td-installation.yaml
Istio mesh is now running with a new trust domain, new-td
.
- Delete secrets of
sleep
andhttpbin
indefault
namespace and insleep-allow
namespace. Notice if you install Istio with SDS,you don’t need to follow this step. Learn more about Provisioning Identity through SDS
$ kubectl delete secrets istio.sleep; kubectl delete secrets istio.httpbin;
$ kubectl delete secrets istio.sleep -n sleep-allow
- Redeploy the
httpbin
andsleep
applications to pick up changes from the new Istio control plane.
$ kubectl delete pod --all
$ kubectl delete pod --all -n sleep-allow
- Verify that requests to
httpbin
from bothsleep
indefault
namespace andsleep-allow
namespace are denied.
$ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
403
$ kubectl exec $(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
403
This is because we specified an authorization policy that deny all requests to httpbin
, except the onesthe old-td/ns/sleep-allow/sa/sleep
identity, which is the old identity of the sleep
application in sleep-allow
namespace.When we migrated to a new trust domain above, i.e. new-td
, the identity of this sleep
application is now new-td/ns/sleep-allow/sa/sleep
,which is not the same as old-td/ns/sleep-allow/sa/sleep
. Therefore, requests from the sleep
application in sleep-allow
namespaceto httpbin
were allowed before are now being denied. Prior to Istio 1.4, the only way to make this work is to change the authorizationpolicy manually. In Istio 1.4, we introduce an easy way, as shown below.
Migrate trust domain with trust domain aliases
- Install Istio with a new trust domain and trust domain aliases.
$ cat <<EOF > ./td-installation.yaml
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
values:
global:
controlPlaneSecurityEnabled: false
mtls:
enabled: true
trustDomain: new-td
trustDomainAliases:
- old-td
EOF
$ istioctl manifest apply --set profile=demo -f td-installation.yaml
Without changing the authorization policy, verify that requests to
httpbin
from:sleep
in thedefault
namespace are denied.
$ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
403
sleep
in thesleep-allow
namespace are allowed.
$ kubectl exec $(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -s -o /dev/null -w "%{http_code}\n"
200
Best practices
Starting from Istio 1.4, when writing authorization policy, you should consider using the value cluster.local
as thetrust domain part in the policy. For example, instead of old-td/ns/sleep-allow/sa/sleep
, it should be cluster.local/ns/sleep-allow/sa/sleep
.Notice that in this case, cluster.local
is not the Istio mesh trust domain (the trust domain is still old-td
). However,in authorization policy, cluster.local
is a pointer that points to the current trust domain, i.e. old-td
(and later new-td
), as well as its aliases.By using cluster.local
in the authorization policy, when you migrate to a new trust domain, Istio will detect this and treat the new trust domainas the old trust domain without you having to include the aliases.
Clean up
$ kubectl delete authorizationpolicy service-httpbin.default.svc.cluster.local
$ kubectl delete deploy httpbin; k delete service httpbin; k delete serviceaccount httpbin
$ kubectl delete deploy sleep; k delete service sleep; k delete serviceaccount sleep
$ kubectl delete namespace sleep-allow
$ istioctl manifest generate --set profile=demo -f td-installation.yaml | kubectl delete -f -
See also
Authorization for HTTP traffic
Shows how to set up role-based access control for HTTP traffic.
Shows how to set up access control for TCP traffic.
Describes Istio's authorization and authentication functionality.
Micro-Segmentation with Istio Authorization
Describe Istio's authorization feature and how to use it in various use cases.
Introducing the Istio v1beta1 Authorization Policy
Introduction, motivation and design principles for the Istio v1beta1 Authorization Policy.
Authorization for groups and list claims
Tutorial on how to configure the groups-base authorization and configure the authorization of list-typed claims in Istio.