Question about Pull Mode Architecture and Permissions

[kahirokunn]

Context

I'm reviewing the Pull Mode documentation and trying to understand the architecture and permission model.

Questions

1. Architecture Comparison with Work API

Is the Pull Mode architecture the same as the Work API from the Kubernetes multicluster SIG? If there are differences, could you clarify what they are?

2. Permission Model Clarification

Based on my understanding, the management cluster:

• Has read permissions to managed clusters (required for features like EventFramework)
• Does not have write permissions to managed clusters

Is this understanding correct? Can Sveltos be configured to ensure the management cluster has no write access to managed clusters?

3. Zero-Access Configuration

If EventFramework is not used for a particular cluster, is it possible to configure Sveltos so that the management cluster has zero access (neither read nor write) to the managed cluster? In other words, can it operate purely as a Work controller where the managed cluster pulls all necessary information?

Thank you for your help in clarifying these architectural and permission aspects! 🙇‍♂️

[gianlucam76]

Hi @kahirokunn in pull mode, the management cluster has zero access to the managed cluster. As a matter of fact, in the management cluster there is no kubeconfig to access the managed clusters.

In pull-mode, the managed cluster has access to the management cluster. But only to fetch the ConfigurationGroup/ConfigurationBundle instances that contain the configuration to deploy in the managed cluster.
What needs to be deployed in a managed cluster is still decided by the management cluster. But the management cluster simply creates ConfigurationGroup/ConfigurationBundle instances containing what needs to be deployed (for instance a Deployment or a ConfigMap etc).
The managed cluster then pulls those ConfigurationGroup/ConfigurationBundle instances and deploy what s needed in the managed cluster.

The managed cluster also has permissions to:

1. update the Status of the SveltosCluster instance in the management cluster representing that specific managed cluster
2. send to management cluster EventReports/ClassifierReports

[gianlucam76]

@kahirokunn can this be closed?

[kahirokunn]

Thank you so much for the detailed explanation!

In pull mode, even when using EventFramework, the management cluster never accesses the managed cluster and doesn't require any kubeconfig for the managed clusters, correct? 👀

[gianlucam76]

Yes that is correct. When in pull mode, management cluster has no access to the managed cluster