Getting Started - Prepare Your Environment ## Exercise 1 - Accessing your Kubernetes Cluster ## Exercise 2 - Installing Istio ## Exercise 3 - Deploy Guestbook with Istio Proxy ## Exercise 4 - Expose the service mesh with the Istio Ingress Gateway ## Exercise 5 - Telemetry ## Exercise 6 - Traffic Management ## Exercise 7 - Security —
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-system
Expected output:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
istio-citadel 1 1 1 1 15h
Define mTLS Authentication Policy
First, we create a MeshPolicy for configuring the receiving end to use mTLS. The following two destination rules will then configure the client side to use mTLS. We’ll update the previously created DestinationRule to include mTLS and create a new blanket rule (*.local) for all other services. Run the following command to enable mTLS across your cluster:
cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
name: "default"
spec:
peers:
- mtls: {}
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "destination"
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: destination-rule-guestbook
spec:
host: guestbook
subsets:
- name: v1
labels:
version: "1.0"
- name: v2
labels:
version: "2.0"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
EOF
You should see:
meshpolicy.authentication.istio.io/default created
destinationrule.networking.istio.io/destination created
destinationrule.networking.istio.io/destination-rule-guestbook configured
Confirm the policy for the receiving services to use mTLS has been created:
kubectl get meshpolicies
Output:
NAME AGE
default 1m
Confirm the destination rules for client-side mTLS has been created:
kubectl get destinationrules
Output:
NAME HOST AGE
destination *.local 3m21s
destination-rule-guestbook guestbook 3m21s
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.
To verify this, you can use an experimental istioctl feature to describe pods.
First, get your pods:
kubectl get pods
Copy the name of the guestbook v2 pod, for exmaple: guestbook-v2-f9f597d8d-zbhkt.
istioctl x describe pod guestbook-v2-f9f597d8d-zbhkt
Please note: istioctl seems to no longer support this experimental (x) command and the Istio documentation offers no replacement.
You should see something like this:
Pod: guestbook-v2-f9f597d8d-zbhkt
Pod Ports: 3000 (guestbook), 15090 (istio-proxy)
--------------------
Service: guestbook
Port: http 80/HTTP targets pod port 3000
DestinationRule: destination-rule-guestbook for "guestbook"
Matching subsets: v2
(Non-matching subsets v1)
Traffic Policy TLS Mode: ISTIO_MUTUAL
Pod is STRICT and clients are ISTIO_MUTUAL
Exposed on Ingress Gateway http://159.23.74.230
VirtualService: virtual-service-guestbook
1 HTTP route(s)
You’ll see that the pod policy is “STRICT” and clients are “ISTIO_MUTUAL”. In addition, note Traffic Policy TLS Mode: ISTIO_MUTUAL.
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.
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
kubectl replace -f v1/guestbook-deployment.yaml
kubectl replace -f v2/guestbook-deployment.yaml
kubectl replace -f v2/analyzer-deployment.yaml
Create a AuthorizationPolicy 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: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: analyzeraccess
spec:
selector:
matchLabels:
app: analyzer
EOF
Output:
authorizationpolicy.security.istio.io/analyzeraccess created
Visit the Guestbook app from your favorite browser and validate that Guestbook v2 does not run correctly by entering some message into the guestbook. For every new message you write 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 the added rules section:
cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: analyzeraccess
spec:
selector:
matchLabels:
app: analyzer
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/guestbook"]
to:
- operation:
methods: ["POST"]
EOF
Visit the Guestbook app from your favorite browser and validate that Guestbook V2 works now. It can take a few seconds for the change to propogate to the envoy sidecar(s) so you may not observe Guestbook V2 to function right away.
Thank you so much for your time today! You’ve done an excellent job making it through the material.