Requirements for Deploying Service Mesh Applications

When you deploy an application into Service Mesh, there are many differences between the behavior of an upstream Istio Community installation and a Maistra installation.

Configuring the Security Constraints for Application Service Accounts

OpenShift 4 uses CNI and does not require these changes. Prior versions of OpenShift still use proxy-init and require the additional permissions discussed below. See also the differences between Maistra and upstream Istio.

When you deploy an application into a Service Mesh running in an OpenShift environment, it is currently necessary to relax the security constraints placed on the application by its service account to ensure that the application can function correctly. Each service account must be granted permissions by using the anyuid and privileged Security Context Constraints (SCC) to enable the sidecars to run correctly.

The privileged security constraint is required to ensure changes to the pod’s networking configuration can be updated successfully with the istio-init initialization container and the anyuid SCC is required to enable the sidecar container to run by using its required user id of 1337.

To configure the correct permissions, it is necessary to identify the service accounts that are being used by your application’s pods. For most applications this is the default service account however your Deployment/DeploymentConfig may override this by providing the serviceAccountName within the pod specification.

For each identified service account you must update the cluster configuration so that they are granted access to the anyuid and privileged security constraints by executing the following commands from an account with cluster admin privileges. Replace <service account> and <project> with values specific to your application.

$ oc adm policy add-scc-to-user anyuid -z <service account> -n <project>
$ oc adm policy add-scc-to-user privileged -z <service account> -n <project>