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

Privileged and anyuid changes are only required when using proxy-init. These can be skipped when using CNI.

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 SCC 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 SCCs 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>

Configuring an Application to Utilize Automatic Sidecar Injection

When deploying an application into the Service Mesh you must opt in to injection by specifying the annotation with a value of true. The decision to opt in is required to ensure the sidecar injection does not interfere with other OpenShift features such as builder pods used by numerous frameworks within the OpenShift ecosystem.

The following example shows the annotation used within the sleep test application. The additional sidecar containers are included when this configuration is deployed within an OpenShift Service Mesh installation.

apiVersion: extensions/v1beta1
kind: Deployment
  name: sleep
  replicas: 1
      annotations: "true"
        app: sleep
      - name: sleep
        image: tutum/curl
        command: ["/bin/sleep","infinity"]
        imagePullPolicy: IfNotPresent

You are not required to label a project to enable automatic sidecar injection unlike in upstream Istio releases. The webhook checks the configuration of pods deploying into all projects in a mesh to see if they are opting in to injection by using the appropriate annotation.