Question: {{< feature-state for_k8s_version="v1.4" state="beta" >}} <del> [AppArmor](https://apparmor.net/) is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either *enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports violations. On Kubernetes, AppArmor can help you to run a more secure deployment by restricting what containers are allowed to do, and/or provide better auditing through system logs. However, it is important to keep in mind that AppArmor is not a silver bullet and can only do so much to protect against exploits in your application code. It is important to provide good, restrictive profiles, and harden your applications and cluster from other angles as well. </del> <ins> This page shows you how to load AppArmor profiles on your nodes and enforce those profiles in Pods. To learn more about how Kubernetes can confine Pods using AppArmor, see [Linux kernel security constraints for Pods and containers](/docs/concepts/security/linux-kernel-security-constraints/#apparmor). </ins> ## {{% heading "objectives" %}}

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The doesn't mention that you can run Pods with AppArmor / seccomp / whatever to constrain the container. Why is this needed Although we have tutorials that explain the concepts in the manner of a walkthough, having a concept guide is important too. It's OK if the mention within is more like a signpost: a hyperlink to another page such as (which doesn't exist). Comments /sig security Relevant to Relevant to
This should be a fun time Since we already talk about privileged mode on the Pods page I agree that it's important to talk about the security constraints that you can place on containers. I also agree that a standalone page that discusses container isolation strategies and kernel-level security measures would be a good addition to our docs. /triage accepted /assign
As a first step, I'll find out if this information exists across our current docs (it definitely does) and draft up a plan for changes.
The framing here should be: small simple soon
Thanks If you're willing to focus first on the minimum viable change that can allow seccomp and AppArmor to graduate with docs in place, that'll help. It does mean more overall work if you then revisit things to make a larger improvement. Sorry about that.
Going through the current content it feels disconnected talking about Privileged mode, without not mentioning isolation levels. For someone starting their learning journey it may be hard to understand what that really means. In my opinion, the existing section could become a higher level section about Security Context (or a brief point on isolation levels), and within there we could talk about the ways of constraining (or enforcing isolation of) the container execution via AppArmor, Seccomp, SELinux and Privileged containers. We probably should use this opportunity to highlight the impact of privileged mode on those constraints. wdyt?
Agreed that it's a bit out of place there.

We already have so I wonder how that fits... Regardless for the mvp for this issue I'll focus on a smaller scope to meet the requirements here and then we can fiddle and improve
Planned here: I'd appreciate reviews on the scope so that I can do a draft and get that reviewed
I drafted the MVP of that page: It's missing some info that I am not sure about
I'd be happy to see a PR anyway.
Still working on this, will send a PR soon
would you like any help here?
I'll open a draft PR in the coming days. One final ish question: The content in (the seccomp and Apparmor/SELinux sections) are a summary basically of the content in this new page. Think it's a good idea to remove that bulk from the checklist page and link to the new page to learn more?
I'd really like to hear your thoughts on Shannon's question in
Security has been one of the top concerns for a few years when people start evaluating k8s. What I'd like to see is a single concept page clearly outlining all relevant topics as links to more detailed references. In this concept page, we may want to articulate the shared-responsibility model where security topics are organized based on users' persona. In other words, as an application developer, what are the things I need to pay attention to? As a cluster operator, what are the best practices I need to check. As someone who prepares the underlying infrastructure, is there a checklist for me?
If merges first, we could build on that. Thoughts there?
I agree - we can expand that page or work it into a more use case based signposting topic. Some considerations though: We should think about how to organize it. There's the CNCF white paper phases, yes, but there's also the opportunity to organize by pillar, like authn/z, encryption, monitoring and logging, etc. Maybe a sensible combination of the two? The links we provide should be associated with specific jobs to be done. For example, in the Authorization pillar, we could have "Authorize actions in clusters" and list the learning journey (About authorization RBAC RBAC good practices RBAC how-to) Maybe we can create a follow-up issue for this and discuss the actual presentation of that information there?
Maybe we can draft a toc for this on google docs for discussion?

sounds good to me, we should probably also create a backlog issue for tracking purposes (I can do it later today I'm away from my computer still waking up )
Relevant to
We can now link from the Pod concept to


Question: <ins> --- title: ノードリソースマネージャー content_type: concept weight: 50 --- <!-- overview --> レイテンシーが致命的なワークロードや高スループットのワークロードをサポートするために、Kubernetesは一連のリソースマネージャーを提供します。リソースマネージャーはCPUやデバイス、メモリ(hugepages)などのリソースの特定の要件が設定されたPodのためにノードリソースの調整と最適化を目指しています。 <!-- body --> メインのマネージャーであるトポロジーマネージャーは[ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)に沿って全体のリソース管理プロセスを調整するKubeletコンポーネントです。 個々のマネージャーの設定は下記のドキュメントで詳しく説明されてます。 - [CPUマネージャーポリシー](/docs/tasks/administer-cluster/cpu-management-policies/) - [デバイスポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [メモリマネージャーポリシー](/docs/tasks/administer-cluster/memory-manager/) </ins>

This is a Feature Request What would you like to be Translate docs/concepts/policy/node-resource- into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: /area localization /language ja /assign
/area localization /language ja /assign
404
/triage accepted


Question: --- title: Kubernetes 安全和信息披露 <del> aliases: [security/] </del> content_type: concept weight: 20 ---

This is a Bug Report Problem: The dockershim alias () now directs to the Chinese localized version () because the same alias exists in multiple files. Proposed Solution: Removal of the alias in the Chinese version of the blog post or updated to be A policy or linter might be worth putting in place for aliases as well to prevent future issues. Page to Update:
/triage accepted /kind bug /language zh
A similar problem occurred some time ago with aliases in security. I just checked a few other files. Aliases field is set: content/zh/docs/reference/issues- content/zh/docs/reference/issues- Aliases field not set (set in version): content/zh/docs/reference/access-authn- Should add a note to the localization or documentation about how to update the field.
/assign


Question: The flow control API involves two kinds of resources. [PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta2-flowcontrol-apiserver-k8s-io) <del> define the available isolation classes, the share of the available concurrency </del> <ins> define the available priority levels, the share of the available concurrency </ins> budget that each can handle, and allow for fine-tuning queuing behavior. [FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1beta2-flowcontrol-apiserver-k8s-io) are used to classify individual inbound requests, matching each to a

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Someone reading was not able to discern the intended meaning of the term "isolation class". See . This term is only used twice, and is used in a way that is synonymous with another term already introduced ("priority level"). I think it would be clearer to replace "isolation class" with "priority level". Proposed Solution: Replace "isolation class" with "priority level". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--This has been there for a while. <!--Additional Information:--
/assign
/triage accepted
This is what I originally posted in the #api-priority-and-fairness Slack channel. Thanks for filing this on GitHub, Mike. !


Question: command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] <del> command = "git submodule update --init --recursive --depth 1 && make deploy-preview" </del> <ins> command = "git submodule update --init --recursive --depth 1 && make non-production-build" </ins> <del> [context.master] # This context is triggered by the `master` branch and allows search indexing </del> <ins> [context.main] # This context is triggered by the `main` branch and allows search indexing </ins> # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" command = "git submodule update --init --recursive --depth 1 && make production-build" <del> # adding in headers to prevent clickjacking [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" </del>

Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented.

May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question:
{{ if .Page.Param "announcement" }}

 {{ T "announcement_title" |  markdownify }}

The announcement banner text (merged in ) is being used as the Google search snippet for docs pages. This may not have been your intention. !
SIG Docs doesn't have a good way to improve Google's indexing algorithm. The text is in an HTML element which should mark it as an aside: content only indirectly related to the main content. I'd characterize this as a Google bug. There are a lot of Google people in the Kubernetes ecosystem but probably not from the web search side. Do you agree with that characterization? /triage awaiting-more-evidence
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : SIG Docs doesn't have a good way to improve Google's indexing algorithm. The text is in an HTML element which should mark it as an aside: content only indirectly related to the main content. /triage awaiting-more-evidence Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority awaiting-more-evidence
I can't find anything suggesting Google has ever ignored elements, and I can find a comment from someone at Google saying they explicitly ignore them ( via ). The supported way to mark something not to go in a snippet is the attribute: , . I can raise a feature request with the search team to ask them to treat like but from a Kubernetes users perspective, changing the site will get to a better outcome quicker.
It sounds useful to add to the announcements.
I would adjust to "fix now"
Yikes, sorry guys! I would also mark as fix now
/priority fix-now
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /priority fix-now Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-priority awaiting-more-evidence /priority critical-urgent

This is a Feature Request The HTML partials, and frontpage-, contain a element which duplicates the element found in the body of the page. This became an issue as the docsy theme updates page anchors in the script . This script depends upon the element and failed to find the H1 - H6 level headings on the page to udpate. What would you like to be Investigate how to include the announcement banner on the docs pages (front page, docs, blog, and so on) without the element. Investigate changes to the corresponding stylesheet. Why is this needed Clean up or adjust the preexisting, related code as well as the current templates and stylesheet. Provide a flexible way to add and remove content such as announcement or banners on the pages. Comments For additional information, see PR .
/assign
/kind cleanup /priority important-soon
/reopen There might be more to do here.
Reopened this issue. <detailsIn response to : /reopen There might be more to do here. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I don't think there's any more work that needs doing here! you can close this off :)
Good. The only thing noted is some different styling per main section (docs vs case studies). /close
Closing this issue. <detailsIn response to : Good. The only thing noted is some different styling per main section (docs vs case studies). /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: Issues should be sorted into different buckets of work using the following labels and definitions. If an issue doesn't have enough information to identify a problem that can be researched, reviewed, or worked on (i.e. the issue doesn't fit into any of the categories below) you should close the issue with a comment explaining why it is being closed. ### Needs Clarification <del> * Issues that need more information from the original submitter to make them actionable.  Issues with this label that aren't followed up within a week may be closed. </del> <ins> * Issues that need more information from the original submitter to make them actionable.  Issues with this label that aren't followed up within a week may be closed. </ins> ### Actionable * Issues that can be worked on with current information (or may need a comment to explain what needs to be done to make it more clear)

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:


Question: TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt). --> 为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 <del> 如果需要，你可以额外部署第三方的安全控制机制，例如以 [准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) </del> <ins> 如果需要，你可以额外部署第三方的安全控制机制， 例如以[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) </ins> 的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 同名的名字空间。 {{< /warning >}}

markdown <img width="681" alt="WX20220809- src="https://user-"
page: /triage accepted /assign
namespace


Question: ## What you can't do with network policies (at least, not yet) <del> As of Kubernetes {{< skew currentVersion >}}, 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. </del> <ins> As of Kubernetes {{< skew currentVersion >}}, 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. </ins> <del> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </del> <ins> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </ins> - Anything TLS related (use a service mesh or ingress controller for this). <del> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </del> <ins> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </ins> - Creation or management of "Policy requests" that are fulfilled by a third party. <del> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </del> <ins> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </ins> - Advanced policy querying and reachability tooling. - The ability to log network security events (for example connections that are blocked or accepted). <del> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </del> <ins> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </ins> ## {{% heading "whatsnext" %}} - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. <del> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </del> <ins> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </ins>

I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign