This feature has 2 separate feature flags marked as ALPHA:
ExternalClusterReference, allows to reference Secrets in the same Namespace where the KamajiControlPlane has been deployed
ExternalClusterReferenceCrossNamespace, allows referencing Secrets in different Namespaces rather than the KamajiControlPlane's one
The said boundaries are subject to the threat modelling of the cluster since Kamaji doesn't provide a policy engine.
The said flags can be enabled as usual feature flags, such as --feature-gates ExternalClusterReference=true or --feature-gates ExternalClusterReferenceCrossNamespace=true.
When the deployment is offloaded to a third cluster, a separate manager is created to take advantage of controller-runtime Manager caching capabilities, reused by other KamajiControlPlane instances referencing the same pair of Secret/key.
To preserve the reactivity expected from having a local TenantControlPlane instance, the same trigger mechanism experienced with Kamaji addons is in place: when changes are occurring to the remote TenantControlPlane, a reconciliation in the Control Plane is triggered too, without the need of having controllers RequeAfter and ensuring the possible reactivity affordable.
Remote TenantControlPlane instances are named with kcp-${kamajiControlPlane.metadata.uid}, and a finalizer will ensure the deletion of dangling Tenant Control Planes upon the Cluster API objects deletion.
Related #105.
This feature has 2 separate feature flags marked as
ALPHA:ExternalClusterReference, allows to reference Secrets in the same Namespace where the KamajiControlPlane has been deployedExternalClusterReferenceCrossNamespace, allows referencing Secrets in different Namespaces rather than the KamajiControlPlane's oneThe said boundaries are subject to the threat modelling of the cluster since Kamaji doesn't provide a policy engine.
The said flags can be enabled as usual feature flags, such as
--feature-gates ExternalClusterReference=trueor--feature-gates ExternalClusterReferenceCrossNamespace=true.When the deployment is offloaded to a third cluster, a separate manager is created to take advantage of controller-runtime Manager caching capabilities, reused by other KamajiControlPlane instances referencing the same pair of Secret/key.
To preserve the reactivity expected from having a local TenantControlPlane instance, the same trigger mechanism experienced with Kamaji addons is in place: when changes are occurring to the remote TenantControlPlane, a reconciliation in the Control Plane is triggered too, without the need of having controllers
RequeAfterand ensuring the possible reactivity affordable.Remote TenantControlPlane instances are named with
kcp-${kamajiControlPlane.metadata.uid}, and a finalizer will ensure the deletion of dangling Tenant Control Planes upon the Cluster API objects deletion.