When you deploy an application into the Service Mesh, there are several differences between the behavior of applications in the upstream community version of Istio and the behavior of applications within a Red Hat OpenShift Service Mesh installation.

Red Hat OpenShift Service Mesh security constraints

The relaxing of security constraints is only necessary during the Red Hat OpenShift Service Mesh Technology Preview.

When you deploy an application into a Service Mesh running in an OpenShift environment, it is necessary to relax the security constraints placed on the application by its service account to ensure the application can function correctly. Each service account must be granted permissions with 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 is updated successfully with the istio-init initialization container and the anyuid SCC is required to enable the sidecar container to run with its required user id of 1337.

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

For each identified service account you must update the cluster configuration to ensure they are granted access to the anyuid and privileged SCCs by executing the following commands from an account with cluster admin privileges.

Configuring Red Hat OpenShift Service Mesh security constraints

Configure service accounts that require additional permissions to run in the Service Mesh with anyuid or privileged Security Context Constraints (SCCs).

You do not need to follow this procedure if you are using OpenShift Container Platform 4.1.

  • Identify the service accounts that require SCC changes.

  • Identify the namespaces associated with the service accounts that require SCC changes.

  1. Identify the service account(s) that require relaxed privileges.

    Replace <service account> and <namespace> with values specific to your application in the commands in this procedure.

  2. Run this command for each service account that requires the anyuid SCC for its associated sidecar container.

    $ oc adm policy add-scc-to-user anyuid -z <service account> -n <namespace>
  3. Run this command for each service account that requires the privileged SCC to allow successful updates to its pod’s networking configuration:

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

Red Hat OpenShift Service Mesh's master configuration

Red Hat OpenShift Service Mesh relies on a proxy sidecar within the application’s pod to provide Service Mesh capabilities to the application. You can enable automatic sidecar injection or manage it manually. Red Hat recommends automatic injection using the annotation with no need to label namespaces. This ensures that your application contains the appropriate configuration for the Service Mesh upon deployment. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods.

The upstream version of Istio injects the sidecar by default if you have labeled the namespace. You are not required to label the namespace with Red Hat OpenShift Service Mesh. However, Red Hat OpenShift Service Mesh requires you to opt in to having the sidecar automatically injected to a deployment. This avoids injecting a sidecar where it is not wanted (for example, build or deploy pods). The webhook checks the configuration of pods deploying into all namespaces to see if they are opting in to injection with the appropriate annotation.

Updating the master configuration

To enable the automatic injection of the Service Mesh sidecar, you must first modify the master configuration on each master node in your OpenShift Container Platform installation to include support for webhooks and signing of Certificate Signing Requests (CSRs).

Updating the master configuration is not necessary if you are running OpenShift Container Platform 4.1.

  1. Change to the directory containing the master configuration file (for example, /etc/origin/master/master-config.yaml).

  2. Create a file named master-config.patch with the following contents:

            apiVersion: apiserver.config.k8s.io/v1alpha1
            kubeConfigFile: /dev/null
            kind: WebhookAdmission
            apiVersion: apiserver.config.k8s.io/v1alpha1
            kubeConfigFile: /dev/null
            kind: WebhookAdmission
  3. In the same directory, issue the following commands to apply the patch to the master-config.yaml file:

    $ cp -p master-config.yaml master-config.yaml.prepatch
    $ oc ex config patch master-config.yaml.prepatch -p "$(cat master-config.patch)" > master-config.yaml
    $ /usr/local/bin/master-restart api && /usr/local/bin/master-restart controllers

Enabling automatic sidecar injection

When deploying an application into the Red Hat OpenShift Service Mesh you must opt in to injection by specifying the sidecar.istio.io/inject annotation with a value of true. Opting in ensures that the sidecar injection does not interfere with other OpenShift features such as builder pods used by numerous frameworks within the OpenShift ecosystem.

  • Identify the deployments for which you want to enable automatic sidecar injection.

  • Locate the application’s yaml configuration file.

  1. Open the application’s configuration yaml file in an editor.

  2. Add sidecar.istio.io/inject to the configuration yaml with a value of true as illustrated here:

    Sleep test application example
    apiVersion: extensions/v1beta1
    kind: Deployment
      name: sleep
      replicas: 1
            sidecar.istio.io/inject: "true"
            app: sleep
          - name: sleep
            image: tutum/curl
            command: ["/bin/sleep","infinity"]
            imagePullPolicy: IfNotPresent
  3. Save the configuration file.

Using manual sidecar injection

Manual injection of the sidecar is supported using the upstream Istio community istioctl command.

When you use manual sidecar injection, ensure you have access to a running cluster so the correct configuration can be obtained from the istio-sidecar-injector configmap within the istio-system namespace.

  1. Unpack the istioctl installation into a directory

  2. Add the istioctl binary to the the bin directory in your PATH.

  3. Run this command to inject the sidecar into your application and pipe the configuration to the oc command to create deployments:

    $ istioctl kube-inject -f app.yaml | oc create -f -
Next steps
  • Deploy applications on Red Hat OpenShift Service Mesh.