[Feat] Client Identity Exchanger

[Somefive]

Proposal: Client Identity Exchanger

Background

In v1.4.0, we have ClientIdentityPenetration feature flag which allows cluster-gateway to pass the hub cluster identity to the managed cluster requests. This ensures that the requests through cluster-gateway to keep consistent identity across all clusters and therefore we can leverage the native Kubernetes RBAC mechanism to deal with the authorization.

Purpose

But there are times that the hub cluster identity is not aligned with the managed cluster identity.

1. For example, in Kubernetes provided by cloud providers, each cluster may have unique ID for its issued identity. Therefore the identity across clusters are not natively consistent. When the problem goes to hybrid cloud, it will be more difficult to manage that.
2. And there are times the user of cluster-gateway may want to use privileges provided by the joined cluster itself, instead of using its own hub cluster identity. This can be seen as a super-user behaviour.

To address the above issues, the ClientIdentityExchanger is proposed here. The ClientIdentityExchanger should be able to exchange identities between the hub cluster and managed clusters depending on the given configuration.

Solution

The ClientIdentityExchanger should work when both ClientIdentityExchanger and ClientIdentityPenetration feature flags are switched on. The ClientIdentityExchanger can be classified into two scopes, one is the global configuration and the other one is the cluster configuration.

1. The global configuration works for all clusters. It can be stored in static files and used by the cluster-gateway. In Kubernetes, we can use ConfigMap/Secret to store it and mount it into the cluster-gateway pod.
2. The cluster configuration works for specific cluster. This data is stored along with the cluster object, such as the cluster.core.oam.dev/client-identity-exchanger-config field in the annotation of cluster secret or OCM managed cluster.

The configuration should be able to describe the rules for exchanging identity, as follows

apiVersion: cluster.core.oam.dev/v1alpha1
kind: ClusterGatewayConfiguration
spec:
  clientIdentityExchanger:
    rules:
    - name: super-user
      source:
        group: sudoer
      type: PrivilegedIdentityExchanger
      priority: 10
    - name: mapping
      source:
        user: user-12345
        cluster: cluster-34567
      target:
        user: user-34567
      type: StaticMappingIdentityExchanger
      priority: 100
    - name: external
      source:
        userPattern: ext-*
      url: http://external.exchanger/
      type: ExternalIdentityExchanger
      priority: 20

We can support three types of exchanger.

• PrivilegedIdentityExchanger will directly use the original identity registered by the cluster.
• StaticMappingIdentityExchanger will make static mappings for the given identity.
• ExternalIdentityExchanger will call external service to provide the identity mapping resources.

[barnettZQG]

ExternalIdentityExchanger Is it dangerous? Are there any scenes?

[Somefive]

ExternalIdentityExchanger Is it dangerous? Are there any scenes?

Currently no. Just add it to proposal as a future extension mechanism. It could be dangerous if the connection between cluster gateway and external service is not secured.