In this lab we explore some of the security features of the Istio service mesh.

By default, Istio is configured such that when a service is deployed onto the mesh, it will take advantage of mutual TLS:

• the service is given an identity as a function of its associated service account and namespace
• an x.509 certificate is issued to the workload (and regularly rotated) and used to identify the workload in calls to other services

In the observability lab, we looked at the Kiali dashboard and noted the lock icons indicating that traffic was secured with mTLS.

We can test whether a mesh workload, such as the customers service, will allow a plain-text request as follows:

1. Create a separate namespace that is not configured with automatic injection.

   kubectl create ns other-ns
   

2. Deploy sleep to that namespace

   kubectl apply -f sleep.yaml -n other-ns
   

3. Verify that the sleep pod has no sidecars:

   kubectl get pod -n other-ns
   

4. Call the customer service from that pod:

   kubectl exec -n other-ns deploy/sleep -- curl -s customers.default
   

The output should look like a list of customers in JSON format.

We conclude that Istio is configured by default to allow plain-text request. This is called permissive mode and is specifically designed to allow services that have not yet fully onboarded onto the mesh to participate.

!!! question "Challenge"

Above, you were asked to create a namespace without marking it for sidecar injection in order to effectively have a client that can call other services without employing mutual TLS.

Can you find another way of achieving the same result?  Can a client be configured explicitly to not use mTLS?

Istio provides the PeerAuthentication custom resource to define peer authentication policy.

1. Apply the following peer authentication policy.

   ??? tldr "mtls-strict.yaml" yaml linenums="1" --8<-- "security/mtls-strict.yaml"

   !!! info

    Strict mtls can be enabled globally by setting the namespace to the name of the Istio root namespace, which by default is `istio-system`
   

2. Verify that the peer authentication has been applied.

   kubectl get peerauthentication
   

kubectl exec -n other-ns deploy/sleep -- curl customers.default

The console output should indicate that the connection was reset by peer.

Another important layer of security is to define an authorization policy, in which we allow only specific services to communicate with other services.

At the moment, any container can, for example, call the customers service or the web-frontend service.

1. Call the customers service.

   kubectl exec deploy/sleep -- curl -s customers
   

2. Call the web-frontend service.

   kubectl exec deploy/sleep -- curl -s web-frontend | head
   

Both calls succeed.

We wish to apply a policy in which only web-frontend is allowed to call customers, and only the ingress gateway can call web-frontend.

Study the below authorization policy.

!!! tldr "authz-policy-customers.yaml" yaml linenums="1" --8<-- "security/authz-policy-customers.yaml"

• The selector section specifies that the policy applies to the customers service.
• Note how the rules have a "from: source: " section indicating who is allowed in.
• The nomenclature for the value of the principals field comes from the spiffe{target=_blank} standard. Note how it captures the service account name and namespace associated with the web-frontend service. This identify is associated with the x.509 certificate used by each service when making secure mtls calls to one another.

Tasks:

• Apply the policy to your cluster.
• Verify that you are no longer able to reach the customers pod from the sleep pod

Can you come up with a similar authorization policy for web-frontend?

• Use a copy of the customers authorization policy as a starting point
• Give the resource an apt name
• Revise the selector to match the web-frontend service
• Revise the rule to match the principal of the ingress gateway

!!! hint

The ingress gateway has its own identity.

Here is a command which can help you find the name of the service account associated with its identity:

```{.shell .language-shell}
kubectl get pod -n istio-system -l app=istio-ingressgateway -o yaml | grep serviceAccountName
```

Use this service account name together with the namespace that the ingress gateway is running in to specify the value for the `principals` field.

Don't forget to verify that the policy is enforced.

• Call both services again from the sleep pod and ensure communication is no longer allowed.
• The console output should contain the message RBAC: access denied.

To prevent the above authorization policies from getting in the way of further exploration in subsequent labs, delete them:

kubectl delete authorizationpolicies --all

In the next lab we show how to use Istio's traffic management features to upgrade the customers service with zero downtime.