Security Best Practices

This section provides some deployment guidelines to help keep a service mesh secure.

Use namespaces for isolation

If there are multiple service operators (a.k.a. SREs)deploying different services in a medium- or large-size cluster, we recommend creating a separateKubernetes namespace for each SRE team to isolate their access.For example, you can create a team1-ns namespace for team1, and team2-ns namespace for team2, suchthat both teams cannot access each other’s services.

If Citadel is compromised, all its managed keys and certificates in the cluster may be exposed.We strongly recommend running Citadel in a dedicated namespace (for example, istio-citadel-ns), to restrict access tothe cluster to only administrators.

Let us consider a three-tier application with three services: photo-frontend,photo-backend, and datastore. The photo SRE team manages thephoto-frontend and photo-backend services while the datastore SRE teammanages the datastore service. The photo-frontend service can accessphoto-backend, and the photo-backend service can access datastore.However, the photo-frontend service cannot access datastore.

In this scenario, a cluster administrator creates three namespaces:istio-citadel-ns, photo-ns, and datastore-ns. The administrator hasaccess to all namespaces and each team only has access to its own namespace.The photo SRE team creates two service accounts to run photo-frontend andphoto-backend respectively in the photo-ns namespace. The datastore SREteam creates one service account to run the datastore service in thedatastore-ns namespace. Moreover, we need to enforce the service accesscontrol in Istio Mixer such thatphoto-frontend cannot access datastore.

In this setup, Kubernetes can isolate the operator privileges on managing the services.Istio manages certificates and keys in all namespacesand enforces different access control rules to the services.