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
Improve docs for NamespaceDefaultLabelName #27377
Improve docs for NamespaceDefaultLabelName #27377
Conversation
Deploy preview for kubernetes-io-vnext-staging processing. Building with commit 0bfff0b https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/6066308ef0ffad000768f3f6 |
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, | ||
the Kubernetes API server defaults newly-added namespaces to have this label set to the | ||
name of the namespace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding correctly, an attacker with access to write labels to namespaces could cannot overwrite the default label provided the feature gate remains enabled. Have I got that right?
(Also, I'm not sure what the behavior is for clusters upgraded from earlier versions - do existing namespaces get this label as well)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, they do :) The correct statement here is that all namespaces (even the old one) get this new label, and it's rewritten.
Actually the label is not persisted as far as I can remember by my tests, but it's still mutated from the original request by the APIServer.
Discussion here: kubernetes/kubernetes#96968 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make clear here, I would change this to
"the Kubernetes API server defaults all namespaces to have this label set to the name of the namespace, even existing namespaces"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like it's a bit stronger than “defaults”, it's enforced and unchangeable. I'll write that - but I'm keen to get this reviewed for technical accuracy!
/sig api-machinery |
Relevant to kubernetes/enhancements#2161 |
The follow-up commit is to match the style guide recommendation to avoid statements about the future in docs. Statements about the future in blog posts, KEPs, etc are fine, of course. |
|
||
## What you can't do with network policies (at least, not yet) | ||
|
||
As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API. | ||
As of Kubernetes {{< skew latestVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Open vSwitch (but it was wrong previously so 🤷♂️ )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might log that as a good-first-issue against master, post release.
content/en/docs/concepts/overview/working-with-objects/namespaces.md
Outdated
Show resolved
Hide resolved
4b2ef7f
to
151a9de
Compare
151a9de
to
0bfff0b
Compare
@rikatz should I make more changes here? |
/assign |
Hey folks sorry. Notification got missed here @sftim @reylejano I will review this in 15 minutes here so this can ship with the release :) |
/lgtm Thanks for improving this doc @sftim |
LGTM label has been added. Git tree hash: 7b18d04918810114d00875ef2970eac6e94fa3cd
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: reylejano, rikatz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Tweak the documentation for namespaces and labels in light of the new
NamespaceDefaultLabelName
behavior.Previews:
/cc rikatz
@jayunit100 FYI - you reviewed the original PR.
Follows on from PR #26995
/milestone 1.21