https://issues.redhat.com/browse/MAISTRA-1351

May create changes for this topic:

https://docs.openshift.com/container-platform/4.3/service_mesh/service_mesh_install/installing-ossm.html#ossm-member-roll-create_installing-ossm

Background from email from 4/14 subject: [istio] The Purpose of CRD on Maistra: ServiceMeshMember”
Raffaele Spazzoli:
I would like to better understand how to use this feature.
From a usability perspective I think it is desirable that a user in a namespace can enroll his namespace in a service mesh.
On the other hand, a servicemesh administrator should be able to give permissions to namespaces to join.
I understand the new ServiceMeshMember enables the former use case. If only that one is available, a malicious user could join a service mesh and maybe gain permissions to talk to an app I shouldn't.
Do we have a way to also implement the second use case?

--------
Rob:
The mesh administrator has to grant 'use' permissions to the user. If the user hasn't been granted permission to use the mesh, ServiceMeshMember creation will be rejected. Details on how to grant permissions is in the product documentation.

The easiest way to think of this is:

ServiceMeshMemberRoll is used by the mesh administrator to control which projects are part of the mesh (note, the mesh administrator must have edit permissions for each project listed).

ServiceMeshMember enables the mesh administrator to delegate access to the mesh to individual users, as opposed to projects.

Background from See e-mail thread 4/14 subject “[istio] The Purpose of CRD on Maistra: ServiceMeshMember”

The two methods are not exclusive, i.e. the mesh admin can specify certain projects through SMMR, while also granting certain users the ability to join the mesh themselves. That said, I'm not sure whether we're supporting using both methods at the same time. Marko, Kev? (I could see a situation where the mesh admin adds a project to SMMR, then user adds SMM for one of the projects in SMMR, then deletes that SMM, effectively removing the project that the mesh admin added. If this is the case, we should add validation to prevent users from creating SMM for projects already listed in SMM.)

Marko:
The initial implementation of the SMM controller was meant to only be an addition to the existing functionality in order to ensure there is no adverse impact on existing users. The SMM controller thus modifies the SMMR.spec (as a user would if they decide to add the project manually). Once we merge the SMMR and SMM controllers, we will be able to have SMMs only affect the status section of the SMMR. Until we merge the controllers, we can't have the SMM controller write to the SMMR status, as only one controller should be writing the status of a particular resource.

Marko again:
I think I get it now.
So with a role binding a mesh administrator gives access to a project to a mesh (note this requires admin not edit from the mesh admin on the project namespace).
Then, a project editor can create a SMMR adding the project to the mesh.
Exactly. The mesh admin determines who can join the mesh. The mesh user then decides which of their projects should be part of the mesh and when. Alternatively, the mesh admin can force projects to be part of the mesh by not giving the use privilege to the user and instead adding the project directly to the SMMR as in the previous versions of the Service Mesh.

In kubernetes it's been historically difficult to manage singletons.
That was one of the reasons why we introduced the ServiceMeshMember resource. If there was no requirement for the admin to centrally specify which namespaces should belong to the mesh, we could get rid of the ServiceMeshMemberRoll resource (or keep it only as a read-only resource used only by the Istio Control Plane components to determine which projects are part of the mesh). This way, there would no longer be a singleton.

How do you manage the situation where a project admin creates two SMMRs pointing to two different meshes?
Not sure if you meant SMMR or SMM. The SMMR validating webhook ensures that you can only create one SMMR (and it's name must be "default"), so that's not a problem. Likewise, the SMM validating webhook also ensures that a project contains at most one SMM resource (again, it's name must be "default"), so it's impossible for a project to be part of two different meshes.