$ oc policy add-role-to-user -n istio-system --role-namespace istio-system mesh-user <user_name>
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
metadata:
name: default
spec:
controlPlaneRef:
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
metadata:
namespace: istio-system
name: mesh-users
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mesh-user
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: alice
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.
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
).
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.
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
You can use the profiles
parameter in the ServiceMeshControlPlane
to specify one or more templates.
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: basic
spec:
profiles:
- default
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.