Allow inclusive configuration of resources to propagate

[yiqigao217]

Issue by hferentschik
Tuesday Mar 16, 2021 at 09:34 GMT
Originally opened as kubernetes-retired/multi-tenancy#1436

---

When synchronizing additional resource types, eg Secrets, it is currently only possible to configure this globally (see #1435) and the propagation configuration only allows to exclude certain resources from propagation (via annotation).

It would be nice to have an inclusive way of configuring propagation as well. For example, assume the root namespace contains multiple secrets and I would like to only propagate specific secrets (something like what reflector does). In this case I would like to annotate the Secret to propagate and maybe somehow configure to which child namespaces it should be propagated.

This might require changing the propagation modes and adding a new one.

[yiqigao217]

Comment by adrianludwin
Tuesday Mar 16, 2021 at 14:40 GMT

---

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.

/good-first-issue

[yiqigao217]

Comment by k8s-ci-robot
Tuesday Mar 16, 2021 at 14:40 GMT

---

@adrianludwin:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.

/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[hferentschik]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[hferentschik]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[erikgb]

/remove-lifecycle stale
/lifecycle frozen

[kristinnardal2]

I have run into exactly this problem.
I'm working with multiple teams which all get a namespace in a Kubernetes cluster, we automatically populate this namespace with docker credentials to a repository that the team has access to.
We would like to allow the teams to create sub-namespaces and have only the docker credentials propagate to the sub-namespaces.

Only being able to exclude secrets makes it so that all automatically generated secrets, such as Helm release secrets, need to be annotated so that they won't get propagated. This is not optimal, when all we want to do is only propagate one single Kubernetes secret to the sub-namespaces.