Add ClusterRbacConfig and deprecate the RbacConfig

[yangminzhu]

Describe the bug
RbacConfig is incorrectly scoped to Namespace but should be Cluster scoped instead. As the scope field of a CRD is immutable, we have to introduce a new ClusterRbacConfig with cluster scope and deprecate the old RbacConfig.

• Add ClusterRbacConfig in pilot and crd.yaml. The logic in pilot should be:
  1. If there is a ClusterRbacConfig, then use it and ignore any RbacConfigs
  2. Fallback to check if there is a RbacConfig, if found then use it
  3. None of ClusterRbacConfig/RbacConfig found, then the RBAC is disabled.

• Update the documentation about the deprecate of RbacConfig and guides how to migrate to ClusterRbacConfig.
  We can provide a subcommand in istioctl to do the migration automatically for the user. (Basically it should copy the content from RbacConfig to ClusterRbacConfig and then remove the RbacConfig CRD)

• After another two releases of Istio, we could remove the RbacConfig completely in the code. There is no formal API deprecate policy for now but it should be fine for RBAC as the API is still in alpha stage.

/cc @ayj @ozevren @diemtvu @liminw

[ayj]

We should be sure to document the deprecation of RBACConfig in the 1.1 release notes.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[rcernich]

Can you provide a link to any discussion around this? Moving to cluster scoped resources effectively prevents multiple installations of Istio (all control planes would share the same default cluster resources; same applies to MeshPolicy), which prevents supporting multitenant installations.

Given the way these are used (providing default behavior for the mesh), I fail to see why they need to be cluster scoped, especially since they need to be named default to begin with. To better support multiple installations and multitenancy, it would be preferable if these remained namespace scoped and the controllers only listed RbacConfig (and Policy) resources in the local namespace (e.g. istio-system) named default.

[yangminzhu]

@rcernich In the next version of Istio authorization, we're changing to put it (also rename to AuthorizationConfig) in the Istio root namespace which means it will be namespace-scoped resource, not cluster-scoped resource. We may still need more efforts to support multi-tenant installations though.

For more information about the next version of Istio authorization, please see https://docs.google.com/document/d/1diwa9oYVwmLtarXb-kfWPq-Ul3O2Ic3b8Y21Z3R8DzQ (accessible in Istio community group)

cc @liminw @diemtvu

[rcernich]

Sounds great. Thanks for the info!

@knrc, fyi

[knrc]

@yangminzhu We've been doing a lot of work on soft multi tenancy and have some updates to the Istio control plane components which would be of interest, this is what sparked our interest in the remaining cluster scoped resources (ClusterRbacConfig and MeshPolicy). We're trying to work out what we should do with these resources to support multiple tenants within the same cluster.

I was talking to @duderino earlier today and mentioned this.

We still have a number of issues to address including how to have the control plane components react better to our dynamic updates for the namespaces (defined in a custom resource), they often don't take too kindly to namespaces disappearing.

[howardjohn]

Are you planning to remove the deprecated CRD in 1.4?

[yangminzhu]

@howardjohn
No, there is not much need to remove the RbacConfig in 1.4 as its successor ClusterRbacConfig is also deprecated by the new AuthorizationPolicy in 1.4.

The next step is to deprecate the old RBAC policy (RbacConfig, ClusterRbacConfig, ServiceRole, ServiceRoleBinding) all together which could be done in 1.5 or 1.6 to allow customer to have enough time to upgrade to AuthorizationPolicy.