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

Prevent virtual cluster users from creating DaemonSets #491

Open
axisofentropy opened this issue Nov 13, 2023 · 0 comments
Open

Prevent virtual cluster users from creating DaemonSets #491

axisofentropy opened this issue Nov 13, 2023 · 0 comments

Comments

@axisofentropy
Copy link
Member

Right now there's nothing preventing users from specifying a DaemonSet within their virtual clusters, although our documentations suggests they are not supported.

When I tried, the virtual cluster accepted the DaemonSet. It even scheduled and started running a Pod.

But most DaemonSets we'll see in the wild will require hostPaths or other direct node access which we cannot permit in our multi-tenant environment and also don't make much "sense" when the nodes are fake.

We're using the default "fake nodes" option: https://www.vcluster.com/docs/architecture/nodes
The documentation has this warning:

If you want to use DaemonSets within vCluster, we recommend to either use the Real Nodes All or Real Nodes Label Selector option, as this will hard delete the nodes that are not there anymore from vCluster. If you are using fake nodes or just the used real nodes option, daemon sets will essentially never let vCluster delete an unused node as it will always be occupied by a daemon set pod.

It may not be easy but it would be great if we could configure k3s to prevent creation of DaemonSets entirely. There may also be other resources we want to prevent.

That said, there's probably not much risk here, so this is probably a low priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Backlog
Development

No branches or pull requests

1 participant