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
Relaxing security constraints is only necessary during the OpenShift Service Mesh Technology Preview phase.
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
privileged Security Context Constraints (SCC) to enable the sidecars to run correctly.
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
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
privileged SCCs by executing the following commands from an account with cluster admin privileges. Replace
<service account> and
<namespace> with values specific to your application.
oc adm policy add-scc-to-user anyuid -z <service account> -n <namespace> oc adm policy add-scc-to-user privileged -z <service account> -n <namespace>
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
sidecar.istio.io/inject 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 metadata: name: sleep spec: replicas: 1 template: metadata: annotations: sidecar.istio.io/inject: "true" labels: app: sleep spec: containers: - name: sleep image: tutum/curl command: ["/bin/sleep","infinity"] imagePullPolicy: IfNotPresent
You are not required to label a namespace to enable automatic sidecar injection unlike in upstream Istio Community releases. The webhook checks the configuration of pods deploying into all namespaces to see if they are opting in to injection by using the appropriate annotation.