Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(feat) central cluster ADR #1

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

auhlig
Copy link
Member

@auhlig auhlig commented Jul 8, 2024

This PR introduces an ADR for the central clusters.

TLDR: I'd like to disallow plugins in the central cluster and move them to a customer-owned cluster to address the various disadvantages and risks the current situation imposes. This should be decided and implemented asap.

## Decision Drivers

* **Network Compatibility**
It assumes that the network zone of the central Greenhouse cluster is suitable for all organizations and cloud providers.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explicit mention: This would enable use cases residing in different hyperscalers.


* No user-configurable plugins should be allowed in the Greenhouse central cluster.
* Maintain restrictive permissions within the central cluster limited to Greenhouse resources.
* Introduce `AdminPlugins` to utilize the plugin concept for handling core responsibilities.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding context from Slack DMs: AdminPlugins in this case could be Plugins such as IdP Integration, Cluster Registry, Greenhouse Teams to Slack syncing, ... . These would all be Plugins which are close the backend (e.g. use Greenhouse CRDs) but are developed separately from the Core Operators.

Copy link
Member Author

@auhlig auhlig Jul 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Sharpen definition AdminPlugins.
kubeconfig generator, CAM integration - things not directly configurable by the user

@auhlig
Copy link
Member Author

auhlig commented Jul 11, 2024

  • Github guard
    • where would it run (centrally or remote)
    • UI access to CRDs in remote cluster. Propagate to/from remote cluster.
    • Proxy access to remote cluster through service proxy channel. only configuration!
    • permission model

TODO:

  • model and discuss 2 use cases: AM + Github guard
  • discuss central cluster as a service. every org with own central cluster. no more multi-tenancy in central cluster.
  • managed central cluster

@uwe-mayer uwe-mayer self-requested a review July 11, 2024 08:48
Thus workload in the central cluster is charged on the provider.

Moreover, workload within the central cluster is neither transparent nor accessible to the customer.
It cannot be configured, its metrics, logs, etc. are not exposed and access (kubectl exec/delete pod) is restricted.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It cannot be configured, its metrics, logs, etc. are not exposed and access (kubectl exec/delete pod) is restricted.
It cannot be configured, and its metrics and logs are not exposed. Access to operations like 'kubectl exec' or 'kubectl delete pods' is restricted in the central cluster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants