23 lines
1.6 KiB
Text
23 lines
1.6 KiB
Text
|
= Service Provider Control Planes
|
||
|
|
|
||
|
|
Control Planes are Kubernetes API endpoints, reachable directly from the Web Portal. It represents a datacenter ("Zone") of a Service Provider.
|
||
|
|
A Service Provider can have multiple zones.
|
||
|
|
|
||
|
|
The portal connects to these Kubernetes API endpoints by using the official https://github.com/kubernetes-client/python[Python Kubernetes Client^].
|
||
|
|
|
||
|
|
Every control plane is registered in the portal database with connection details, names and other metadata (description, location, service provider, zone, logo, etc.).
|
||
|
|
|
||
|
|
Authentication happens via different mechanisms, depending on the task at hand:
|
||
|
|
|
||
|
|
System Connections::
|
||
|
|
Certain operations are initiated directly by the portal, for example retrieving the available service definitions (XRDs).
|
||
|
|
This is done via a dedicated Service Account token, having stringent RBAC rules on the cluster.
|
||
|
|
|
||
|
|
User Connections::
|
||
|
|
Tasks like creating, listing, updating, or deleting service instances is done in the users context. On the Kubernetes API, we take appropriate measure to secure the access.
|
||
|
|
For acting in the users context, we use:
|
||
|
|
. https://www.keycloak.org/securing-apps/token-exchange[OIDC Token Exchange] to get a token to authenticate in the users context against the control plane API.
|
||
|
|
. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation[User impersonation] by using the system connections credentials.
|
||
|
|
|
||
|
|
Not all users and organizations have access to all control planes, therefore we implement access control on a user and organization level to control planes.
|
||
|
|
This way we filter the available service providers available.
|