Creating the Red Hat OpenShift Service Mesh members

ServiceMeshMember resources provide a way for Red Hat OpenShift Service Mesh administrators to delegate permissions to add projects to a service mesh, even when the respective users don’t have direct access to the service mesh project or member roll. While project administrators are automatically given permission to create the ServiceMeshMember resource in their project, they cannot point it to any ServiceMeshControlPlane until the service mesh administrator explicitly grants access to the service mesh. Administrators can grant users permissions to access the mesh by granting them the mesh-user user role. In this example, istio-system is the name of the Service Mesh control plane project.

$ oc policy add-role-to-user -n istio-system --role-namespace istio-system mesh-user <user_name>

Administrators can modify the mesh-user role binding in the Service Mesh control plane project to specify the users and groups that are granted access. The ServiceMeshMember adds the project to the ServiceMeshMemberRoll within the Service Mesh control plane project that it references.

apiVersion: maistra.io/v1
kind: ServiceMeshMember
  name: default
    namespace: istio-system
    name: basic

The mesh-users role binding is created automatically after the administrator creates the ServiceMeshControlPlane resource. An administrator can use the following command to add a role to a user.

$ oc policy add-role-to-user

The administrator can also create the mesh-user role binding before the administrator creates the ServiceMeshControlPlane resource. For example, the administrator can create it in the same oc apply operation as the ServiceMeshControlPlane resource.

This example adds a role binding for alice:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
  namespace: istio-system
  name: mesh-users
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: mesh-user
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: alice

Creating Service Mesh control plane profiles

You can create reusable configurations with ServiceMeshControlPlane profiles. Individual users can extend the profiles they create with their own configurations. Profiles can also inherit configuration information from other profiles. For example, you can create an accounting control plane for the accounting team and a marketing control plane for the marketing team. If you create a development template and a production template, members of the marketing team and the accounting team can extend the development and production profiles with team-specific customization.

When you configure Service Mesh control plane profiles, which follow the same syntax as the ServiceMeshControlPlane, users inherit settings in a hierarchical fashion. The Operator is delivered with a default profile with default settings for Red Hat OpenShift Service Mesh.

Creating the ConfigMap

To add custom profiles, you must create a ConfigMap named smcp-templates in the openshift-operators project. The Operator container automatically mounts the ConfigMap.

  • An installed, verified Service Mesh Operator.

  • An account with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you must have an account with the dedicated-admin role.

  • Location of the Operator deployment.

  • Access to the OpenShift CLI (oc).

  1. Log in to the OpenShift Container Platform CLI as a cluster-admin. If you use Red Hat OpenShift Dedicated, you must have an account with the dedicated-admin role.

  2. From the CLI, run this command to create the ConfigMap named smcp-templates in the openshift-operators project and replace <profiles-directory> with the location of the ServiceMeshControlPlane files on your local disk:

    $ oc create configmap --from-file=<profiles-directory> smcp-templates -n openshift-operators
  3. You can use the profiles parameter in the ServiceMeshControlPlane to specify one or more templates.

      apiVersion: maistra.io/v2
      kind: ServiceMeshControlPlane
        name: basic
        - default

Setting the correct network policy

Service Mesh creates network policies in the Service Mesh control plane and member namespaces to allow traffic between them. Before you deploy, consider the following conditions to ensure the services in your service mesh that were previously exposed through an OpenShift Container Platform route.

  • Traffic into the service mesh must always go through the ingress-gateway for Istio to work properly.

  • Deploy services external to the service mesh in separate namespaces that are not in any service mesh.

  • Non-mesh services that need to be deployed within a service mesh enlisted namespace should label their deployments maistra.io/expose-route: "true", which ensures OpenShift Container Platform routes to these services still work.