Change:
weight: 85 description: > Concepts for keeping your cloud-native workload secure. <ins> simple_list: true </ins> --- <ins> This section of the Kubernetes documentation aims to help you learn to run workloads more securely, and about the essential aspects of keeping a Kubernetes cluster secure. Kubernetes is based on a cloud-native architecture, and draws on advice from the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} about good practice for cloud native information security. Read [Cloud Native Security and Kubernetes](/docs/concepts/security/cloud-native-security/) for the broader context about how to secure your cluster and the applications that you're running on it. ## Kubernetes security mechanisms {#security-mechanisms} Kubernetes includes several APIs and security controls, as well as ways to define [policies](#policies) that can form part of how you manage information security. ### Control plane protection A key security mechanism for any Kubernetes cluster is to [control access to the Kubernetes API](/docs/concepts/security/controlling-access). Kubernetes expects you to configure and use TLS to provide [data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) within the control plane, and between the control plane and its clients. You can also enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for the data stored within Kubernetes control plane; this is separate from using encryption at rest for your own workloads' data, which might also be a good idea. ### Secrets The [Secret](/docs/concepts/configuration/secret/) API provides basic protection for configuration values that require confidentiality. ### Workload protection Enforce [Pod security standards](/docs/concepts/security/pod-security-standards/) to ensure that Pods and their containers are isolated appropriately. You can also use [RuntimeClasses](/docs/concepts/containers/runtime-class) to define custom isolation if you need it. [Network policies](/docs/concepts/services-networking/network-policies/) let you control network traffic between Pods, or between Pods and the network outside your cluster. You can deploy security controls from the wider ecosystem to implement preventative or detective controls around Pods, their containers, and the images that run in them. ### Auditing Kubernetes [audit logging](/docs/tasks/debug/debug-cluster/audit/) provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster. The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself. ## Cloud provider security {{% thirdparty-content vendor="true" %}} If you are running a Kubernetes cluster on your own hardware or a different cloud provider, consult your documentation for security best practices. Here are links to some of the popular cloud providers' security documentation: {{< table caption="Cloud provider security" >}} IaaS Provider        | Link | -------------------- | ------------ | Alibaba Cloud | https://www.alibabacloud.com/trust-center | Amazon Web Services | https://aws.amazon.com/security | Google Cloud Platform | https://cloud.google.com/security | Huawei Cloud | https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | Oracle Cloud Infrastructure | https://www.oracle.com/security | VMware vSphere | https://www.vmware.com/security/hardening-guides | {{< /table >}} ## Policies You can define security policies using Kubernetes-native mechanisms, such as [NetworkPolicy](/docs/concepts/services-networking/network-policies/) (declarative control over network packet filtering) or [ValidatingAdmisisonPolicy](/docs/reference/access-authn-authz/validating-admission-policy/) (declarative restrictions on what changes someone can make using the Kubernetes API). However, you can also rely on policy implementations from the wider ecosystem around Kubernetes. Kubernetes provides extension mechanisms to let those ecosystem projects implement their own policy controls on source code review, container image approval, API access controls, networking, and more. For more information about policy mechanisms and Kubernetes, read [Policies](/docs/concepts/policy/). ## {{% heading "whatsnext" %}} Learn about related Kubernetes security topics: * [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/) * [Known vulnerabilities](/docs/reference/issues-security/official-cve-feed/) in Kubernetes (and links to further information) * [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) * [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) * [Network policies](/docs/concepts/services-networking/network-policies/) for Pods * [Secrets in Kubernetes](/docs/concepts/configuration/secret/) * [Pod security standards](/docs/concepts/security/pod-security-standards/) * [RuntimeClasses](/docs/concepts/containers/runtime-class) Learn the context: <!-- if changing this, also edit the front matter of content/en/docs/concepts/security/cloud-native-security.md to match; check the no_list setting --> * [Cloud Native Security and Kubernetes](/docs/concepts/security/cloud-native-security/) Get certified: * [Certified Kubernetes Security Specialist](https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/) certification and official training course. Read more in this section: </ins>

Discussion:
This is a Refactor request <!-- 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: The overview page at is a bit out of date: no reference to I'm not convinced that the “Four Cs of cloud native security” model is useful for readers to learn Does not align with other CNCF documents, such as Proposed Solution: Either: remove outright migrate content from into several destinations (keep this brief but on-point) &hellip;and then redirect to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig docs /sig security /language en
If we keep the link to then we should update it to be as this is the English docs.
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /triage accepted
Also see
/assign
I'd appreciate a (fresh) review on .