[Feature] New Authentication Module

[aleoli]

Authentication Module

This feature proposes a new authentication module, replacing the current one, in order to simplify its operations (e.g., by limiting cross-cluster interactions, such as request/offers) and bringing in more modularity (e.g., declarative operations). It is based on the concept of Identity and Tenant resources, which are used to authenticate and authorize the communication between two clusters: the provider (the cluster that provides resources) and the consumer (the cluster that consumes resources).

Design Goals

• Fully declarative with CRDs
  • pluggable and extensible
• The provider cluster should NOT have permission over the consumer
  • no resource should be replicated from provider to consumer
  • no port exposition is required from the consumer side (for the API server)
• Resource hierarchy to make it possible to revoke permissions and have better visibility and readability
• Signed first authentication
  • all the other interactions are done with the credentials created in the first step

New Resources

Identity

The Identity resource is the owner of a Kubeconfig secret, that can be used both by Liqo controllers and by the user to access the provider cluster.

They can be of two kinds: Control Plane or Resource; with different permissions and purposes.

Only one Identity resource of kind Control Plane can be created for each provider cluster. Multiple Identity resources of kind Resource can be created for each provider cluster.

Spec

Field	Description	Optional
ClusterID	The ID of the cluster the identity is targeting to
API Server	The API Server address of the cluster the identity is targeting to
CA	The CA of the cluster the identity is targeting to
SignedCertificate	The signed certificate for this identity
Type	The type for this identity (one of ControlPlane or Resource)

Status

Field	Description	Optional
SecretRef	The reference to the secret containing the Kubeconfig created for this identity

ResourceSlice

The ResourceSlice resource is used to request resources from a provider cluster and map how much of them are provided.

There could be multiple ResourceSlice resources for each provider cluster, each one with a different amount of resources requested.

For each ResourceSlice resource, a new Identity resource is created, and the Kubeconfig secret ref is stored in the Status of the ResourceSlice resource.

ResourceSlices can have different classes, to allow the provider cluster to have different policies for different resources. By default, the provider Liqo controllers will accept all the ResourceSlice resources allowing the usage of all the requested resources.

Spec

Field	Description	Optional
Resources	The amount of resources requested to the provider cluster	v
Class	The class for this slice, similar to ingress classes
ClusterID	The ID of the consumer cluster

Status

Field	Description	Optional
State	The state for this slice (one of Accepted or Denied)
Resources	The amount of resources provided by the provider cluster
AuthParams	The parameters required to fill an identity spec

Tenant

The Tenant resource maps the consumer cluster in the provider cluster, and it is the owner of a tenant namespace.

Only one Tenant resource can be created for each consumer cluster.

Spec

Field	Description	Optional
ClusterID	The ID of the cluster the tenant is referring to
PublicKey	The public key of the cluster the identity is referring to
CSR	The CSR of the cluster the identity is referring to
Signature	The signature proving the identity of the consumer cluster

Status

Field	Description	Optional
TenantNamespace	The name of the controlled tenant namespace
AuthParams	The parameters required to fill an identity spec

Workflow

Control Plane

The Control Plane is the first step of the authentication process, and it is used to authenticate the consumer cluster to the provider cluster and to provide the consumer cluster with a Kubeconfig to manage Liqo control plane resources and to check the health of the provider cluster.

• A new pair of private and public keys will be created in the cluster when Liqo is installed
  • this will be the key of the cluster, used to sign and to authenticate
• A nonce is used to prove that the consumer has the private key
  • prevents impersonation
• The Tenant resource keeps the clusterID and its public key
  • it is the parent of the tenant namespace, where all Liqo control plane resources will live
• The Identity resource keeps all the info required to create a Kubeconfig
• Used by Liqo Control Plane (CRD Replicator, API server health check, …)

In the schema, dashed arrows represent manual actions where the user (or software acting for him) needs to move data between the two clusters. In that way, no automatic action is performed between clusters by Liqo components, leading to full declarativity.

Interactions

The schema shows the lowest level interaction required to set up this step by using liqoctl. Those steps can be wrapped by another liqoctl command, in which the user is the owner of both clusters, and they are reachable at the same time from the same machine.

Resource Acquisition

Resource Acquisition is the second step of the authentication process, and it is used to authenticate the consumer cluster to the provider cluster and to provide the consumer cluster with a Kubeconfig to manage the computing resources requested and scheduled to the provider cluster.

• It can be done multiple times for each provider cluster
• A new CR tracks a new set of resources that are made available by using the related Kubeconfig
• A webhook may be implemented in the provider cluster to enforce its utilization
• Multiple Resource Negotiations can be shared between the same couple of clusters
• Multiple controllers can fill the RN Status based on class (similar to ingress classes)
  • pluggability
• The resulting Kubeconfig can be mounted by one or more virtual nodes or used with kubectl

In the schema, red arrows represent resources replicated by the Liqo CRD Replicator; no manual action is required.

Interactions

The schema shows the lowest level interaction required to set up this step by using liqoctl. The only step is creating the ResoruceSlice resource; then, everything is handled by the CRD replicator.

The creation of the related VirtualNode may be automatized by setting an annotation over the ResourceSlice.

[tiwatsuka]

@aleoli I'm interested in the feature discussed #1768 and here. Would this improvement solve #1494? For example, if a foreign cluster could be devided into some virtual nodes by the labels of actual nodes, we can offload pods to nodes with specific labels by setting NodeSelector or NodeAffinity.

[aleoli]

Hi @tiwatsuka! Yes, this, in combination with a custom offloading patch for each virtual node, could solve this issue

[tiwatsuka]

Thank you @aleoli. That sounds great! Could I ask you when is the feature released?

[aleoli]

It should be released in the next weeks as a release candidate for testing and a release at the end of July