Istio can secure the communication between microservices without requiring application code changes. Security is provided by authenticating and encrypting communication paths within the cluster. This is becoming a common security and compliance requirement. Delegating communication security to Istio (as opposed to implementing TLS in each microservice), ensures that your application will be deployed with consistent and manageable security policies.
Istio Citadel is an optional part of Istio's control plane components. When enabled, it provides each Envoy sidecar proxy with a strong (cryptographic) identity, in the form of a certificate. Identity is based on the microservice's service account and is independent of its specific network location, such as cluster or current IP address. Envoys then use the certificates to identify each other and establish an authenticated and encrypted communication channel between them.
Citadel is responsible for:
- Providing each service with an identity representing its role.
- Providing a common trust root to allow Envoys to validate and authenticate each other.
- Providing a key management system, automating generation, distribution, and rotation of certificates and keys.
When an application microservice connects to another microservice, the communication is redirected through the client side and server side Envoys. The end-to-end communication path is:
- Local TCP connection (i.e.,
localhost, not reaching the "wire") between the application and Envoy (client- and server-side); - Mutually authenticated and encrypted connection between Envoy proxies.
When Envoy proxies establish a connection, they exchange and validate certificates to confirm that each is indeed connected to a valid and expected peer. The established identities can later be used as basis for policy checks (e.g., access authorization).
-
Ensure Citadel is running
Citadel is Istio's in-cluster Certificate Authority (CA) and is required for generating and managing cryptographic identities in the cluster. Verify Citadel is running:
kubectl get deployment -l istio=citadel -n istio-systemExpected output:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE istio-citadel 1 1 1 1 15h -
Define mTLS Authentication Policy
Define mTLS authentication policy for the analyzer service:
cat <<EOF | kubectl create -f -
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: mtls-to-analyzer
namespace: default
spec:
targets:
- name: analyzer
peers:
- mtls:
EOF
You should see:
policy.authentication.istio.io/mtls-to-analyzer created
Confirm the policy has been created:
kubectl get policies.authentication.istio.io
Output:
NAME AGE
mtls-to-analyzer 1m
- Enable mTLS from guestbook using a Destination rule
cat <<EOF | kubectl create -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: route-with-mtls-for-analyzer
namespace: default
spec:
host: "analyzer.default.svc.cluster.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
EOF
Output:
destinationrule.networking.istio.io/route-with-mtls-for-analyzer created
If mTLS is working correctly, the Guestbook app should continue to operate as expected, without any user visible impact. Istio will automatically add (and manage) the required certificates and private keys.
Istio support Role Based Access Control(RBAC) for HTTP services in the service mesh. Let's leverage this to configure access among guestbook and analyzer services.
- Create service accounts for the guestbook and analyzer services.
kubectl create sa guestbook
kubectl create sa analyzer
-
Modify guestbook and analyzer deployments to use leverage the service accounts.
-
Navigate to your guestbook dir first, for example:
cd ../../../guestbook -
Add serviceaccount to your guestbook and analyzer deployments
echo " serviceAccountName: guestbook" >> v1/guestbook-deployment.yaml
echo " serviceAccountName: guestbook" >> v2/guestbook-deployment.yaml
echo " serviceAccountName: analyzer" >> v2/analyzer-deployment.yaml
-
redeploy the guestbook and analyzer deployments
kubectl replace -f v1/guestbook-deployment.yaml kubectl replace -f v2/guestbook-deployment.yaml kubectl replace -f v2/analyzer-deployment.yaml -
Create a RBAC configuration to disable all access to analyzer service. This will effectively not allow guestbook or any services to access it.
cat <<EOF | kubectl create -f -
apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
name: default
spec:
mode: 'ON_WITH_INCLUSION'
inclusion:
services: ["analyzer.default.svc.cluster.local"]
EOF
Output:
rbacconfig.rbac.istio.io/default created
- Visit the Guestbook app from your favorite browser and validate that Guestbook V1 continue to work while Guestbook V2 will not run correctly. For every message you wrote on the Guestbook v2 app, you will get a message such as "Error - unable to detect Tone from the Analyzer service". It can take up to 15 seconds for the change to propogate to the envoy sidecar(s) so you may not see the error right away.
- Configure the Analyzer service to only allow access from the Guestbook service using service role and service role binding:
cat <<EOF | kubectl apply -f -
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: analyzer-viewer
namespace: default
spec:
rules:
- services: ["analyzer.default.svc.cluster.local"]
methods: ["POST"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: bind-analyzer
namespace: default
spec:
subjects:
- user: "cluster.local/ns/default/sa/guestbook"
roleRef:
kind: ServiceRole
name: "analyzer-viewer"
EOF
- Visit the Guestbook app from your favorite browser and validate that Guestbook V1 and V2 both work now. It can take up to 15 seconds for the change to propogate to the envoy sidecar(s) so you may not observe Guestbook V2 to function right away.
Run the following commands to clean up the Istio configuration resources as part of this exercise:
kubectl delete policy mtls-to-analyzer
kubectl delete dr route-with-mtls-for-analyzer
kubectl delete rbacconfig default
kubectl delete servicerole analyzer-viewer
kubectl delete servicerolebinding bind-analyzer
True or False?
- Istio Citadel provides each microservice with a strong, cryptographic, identity in the form of a certificate. The certificates' life cycle is fully managed by Istio. (True)
- Istio provides microservices with mutually authenticated connections, without requiring app code changes. (True)
- Mutual authentication must be on or off for the entire cluster, gradual adoption is not possible. (False)