Repository navigation
feat: add --token option for pull-mode cluster registration - #450
Merged
Merged
Conversation
Pull-mode clusters registered today get a long-lived, non-renewing Secret of type kubernetes.io/service-account-token. This PR adds an opt-in alternative for `register cluster --pullmode`: a short-lived token that sveltoscluster-manager renews automatically going forward, bringing pull mode to parity with what push-mode registration already does by default. New flags, only meaningful with --pullmode: - `--token`: use TokenRequest instead of the static SA-token Secret, and configure the SveltosCluster's TokenRequestRenewalOption so sveltoscluster-manager renews it (1h interval, 24h token duration). - `--management-cluster-url=<url>`: required with --token. The management cluster's externally reachable API server address (e.g. https://<host>:<port>), including scheme. sveltoscluster-manager runs in-cluster, so its own view of that address is typically an internal one (the kubernetes.default.svc ClusterIP) the managed cluster can't reach, and on at least one provider (Civo) its in-cluster CA doesn't validate the external endpoint's certificate either. This command already has a working connection to the right endpoint (it's what registration itself uses), so it persists both the address and its own ambient CA data into a ConfigMap (server / ca.crt) for sveltoscluster-manager to read back on every renewal instead of guessing. - `--sveltos-namespace=<name>`: where sveltoscluster-manager itself is installed (defaults to "projectsveltos"). Used to scope the RBAC grant below to the right identity. Also creates a namespace-scoped Role/RoleBinding per cluster, granting sveltoscluster-manager's own ServiceAccount `create` on `serviceaccounts/token`, restricted via resourceNames to that one cluster's ServiceAccount — not a blanket grant on sveltoscluster-manager's own ClusterRole, so it can only ever renew tokens for clusters actually registered with --token. deregisterSveltosCluster cleans up the new Role/RoleBinding and ConfigMap alongside the existing pull-mode resources.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull-mode clusters registered today get a long-lived, non-renewing Secret of type kubernetes.io/service-account-token. This PR adds an opt-in alternative for
register cluster --pullmode: a short-lived token that sveltoscluster-manager renews automatically going forward, bringing pull mode to parity with what push-mode registration already does by default.New flags, only meaningful with --pullmode:
--token: use TokenRequest instead of the static SA-token Secret, and configure the SveltosCluster's TokenRequestRenewalOption so sveltoscluster-manager renews it (1h interval, 24h token duration).--management-cluster-url=<url>: required with --token. The management cluster's externally reachable API server address (e.g. https://:), including scheme. sveltoscluster-manager runs in-cluster, so its own view of that address is typically an internal one (the kubernetes.default.svc ClusterIP) the managed cluster can't reach, and on at least one provider (Civo) its in-cluster CA doesn't validate the external endpoint's certificate either. This command already has a working connection to the right endpoint (it's what registration itself uses), so it persists both the address and its own ambient CA data into a ConfigMap (server / ca.crt) for sveltoscluster-manager to read back on every renewal instead of guessing.--sveltos-namespace=<name>: where sveltoscluster-manager itself is installed (defaults to "projectsveltos"). Used to scope the RBAC grant below to the right identity.Also creates a namespace-scoped Role/RoleBinding per cluster, granting sveltoscluster-manager's own ServiceAccount
createonserviceaccounts/token, restricted via resourceNames to that one cluster's ServiceAccount — not a blanket grant on sveltoscluster-manager's own ClusterRole, so it can only ever renew tokens for clusters actually registered with --token.deregisterSveltosCluster cleans up the new Role/RoleBinding and ConfigMap alongside the existing pull-mode resources.