Merge pull request #43176 from sftim/20230923_revise_security_concept_section
Move and revise overview for Security sectionpull/45183/head
Kubernetes Prow Robot
GitHub
commit
da14ff8f59
|
|
@ -3,4 +3,127 @@ title: "Security"
|
|||
weight: 85
|
||||
description: >
|
||||
Concepts for keeping your cloud-native workload secure.
|
||||
simple_list: true
|
||||
---
|
||||
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,226 @@
|
|||
---
|
||||
title: "Cloud Native Security and Kubernetes"
|
||||
linkTitle: "Cloud Native Security"
|
||||
weight: 10
|
||||
|
||||
# The section index lists this explicitly
|
||||
hide_summary: true
|
||||
|
||||
description: >
|
||||
Concepts for keeping your cloud-native workload 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 on through this page for an overview of how Kubernetes is designed to
|
||||
help you deploy a secure cloud native platform.
|
||||
|
||||
## Cloud native information security
|
||||
|
||||
{{< comment >}}
|
||||
There are localized versions available of this whitepaper; if you can link to one of those
|
||||
when localizing, that's even better.
|
||||
{{< /comment >}}
|
||||
|
||||
The CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
|
||||
on cloud native security defines security controls and practices that are
|
||||
appropriate to different _lifecycle phases_.
|
||||
|
||||
## _Develop_ lifecycle phase {#lifecycle-phase-develop}
|
||||
|
||||
- Ensure the integrity of development environments.
|
||||
- Design applications following good practice for information security,
|
||||
appropriate for your context.
|
||||
- Consider end user security as part of solution design.
|
||||
|
||||
To achieve this, you can:
|
||||
|
||||
1. Adopt an architecture, such as [zero trust](https://glossary.cncf.io/zero-trust-architecture/),
|
||||
that minimizes attack surfaces, even for internal threats.
|
||||
1. Define a code review process that considers security concerns.
|
||||
1. Build a _threat model_ of your system or application that identifies
|
||||
trust boundaries. Use that to model to identify risks and to help find
|
||||
ways to treat those risks.
|
||||
1. Incorporate advanced security automation, such as _fuzzing_ and
|
||||
[security chaos engineering](https://glossary.cncf.io/security-chaos-engineering/),
|
||||
where it's justified.
|
||||
|
||||
## _Distribute_ lifecycle phase {#lifecycle-phase-distribute}
|
||||
|
||||
- Ensure the security of the supply chain for container images you execute.
|
||||
- Ensure the security of the supply chain for the cluster and other components
|
||||
that execute your application. An example of another component might be an
|
||||
external database that your cloud-native application uses for persistence.
|
||||
|
||||
To achieve this, you can:
|
||||
|
||||
1. Scan container images and other artifacts for known vulnerabilities.
|
||||
1. Ensure that software distribution uses encryption in transit, with
|
||||
a chain of trust for the software source.
|
||||
1. Adopt and follow processes to update dependencies when updates are
|
||||
available, especially in response to security announcements.
|
||||
1. Use validation mechanisms such as digital certificates for supply
|
||||
chain assurance.
|
||||
1. Subscribe to feeds and other mechanisms to alert you to security
|
||||
risks.
|
||||
1. Restrict access to artifacts. Place container images in a
|
||||
[private registry](/docs/concepts/containers/images/#using-a-private-registry)
|
||||
that only allows authorized clients to pull images.
|
||||
|
||||
## _Deploy_ lifecycle phase {#lifecycle-phase-deploy}
|
||||
|
||||
Ensure appropriate restrictions on what can be deployed, who can deploy it,
|
||||
and where it can be deployed to.
|
||||
You can enforce measures from the _distribute_ phase, such as verifying the
|
||||
cryptographic identity of container image artifacts.
|
||||
|
||||
When you deploy Kubernetes, you also set the foundation for your
|
||||
applications' runtime environment: a Kubernetes cluster (or
|
||||
multiple clusters).
|
||||
That IT infrastructure must provide the security guarantees that higher
|
||||
layers expect.
|
||||
|
||||
## _Runtime_ lifecycle phase {#lifecycle-phase-runtime}
|
||||
|
||||
The Runtime phase comprises three critical areas: [compute](#protection-runtime-compute),
|
||||
[access](#protection-runtime-access), and [storage](#protection-runtime-storage).
|
||||
|
||||
|
||||
### Runtime protection: access {#protection-runtime-access}
|
||||
|
||||
The Kubernetes API is what makes your cluster work. Protecting this API is key
|
||||
to providing effective cluster security.
|
||||
|
||||
Other pages in the Kubernetes documentation have more detail about how to set up
|
||||
specific aspects of access control. The [security checklist](/docs/concepts/security/security-checklist/)
|
||||
has a set of suggested basic checks for your cluster.
|
||||
|
||||
Beyond that, securing your cluster means implementing effective
|
||||
[authentication](/docs/concepts/security/controlling-access/#authentication) and
|
||||
[authorization](/docs/concepts/security/controlling-access/#authorization) for API access. Use [ServiceAccounts](/docs/concepts/security/service-accounts/) to
|
||||
provide and manage security identities for workloads and cluster
|
||||
components.
|
||||
|
||||
Kubernetes uses TLS to protect API traffic; make sure to deploy the cluster using
|
||||
TLS (including for traffic between nodes and the control plane), and protect the
|
||||
encryption keys. If you use Kubernetes' own API for
|
||||
[CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/#certificate-signing-requests),
|
||||
pay special attention to restricting misuse there.
|
||||
|
||||
### Runtime protection: compute {#protection-runtime-compute}
|
||||
|
||||
{{< glossary_tooltip text="Containers" term_id="container" >}} provide two
|
||||
things: isolation between different applications, and a mechanism to combine
|
||||
those isolated applications to run on the same host computer. Those two
|
||||
aspects, isolation and aggregation, mean that runtime security involves
|
||||
trade-offs and finding an appropriate balance.
|
||||
|
||||
Kubernetes relies on a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
to actually set up and run containers. The Kubernetes project does
|
||||
not recommend a specific container runtime and you should make sure that
|
||||
the runtime(s) that you choose meet your information security needs.
|
||||
|
||||
To protect your compute at runtime, you can:
|
||||
|
||||
1. Enforce [Pod security standards](/docs/concepts/security/pod-security-standards/)
|
||||
for applications, to help ensure they run with only the necessary privileges.
|
||||
1. Run a specialized operating system on your nodes that is designed specifically
|
||||
for running containerized workloads. This is typically based on a read-only
|
||||
operating system (_immutable image_) that provides only the services
|
||||
essential for running containers.
|
||||
|
||||
Container-specific operating systems help to isolate system components and
|
||||
present a reduced attack surface in case of a container escape.
|
||||
1. Define [ResourceQuotas](/docs/concepts/policy/resource-quotas/) to
|
||||
fairly allocate shared resources, and use
|
||||
mechanisms such as [LimitRanges](/docs/concepts/policy/limit-range/)
|
||||
to ensure that Pods specify their resource requirements.
|
||||
1. Partition workloads across different nodes.
|
||||
Use [node isolation](/docs/concepts/scheduling-eviction/assign-pod-node/#node-isolation-restriction)
|
||||
mechanisms, either from Kubernetes itself or from the ecosystem, to ensure that
|
||||
Pods with different trust contexts are run on separate sets of nodes.
|
||||
1. Use a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
that provides security restrictions.
|
||||
1. On Linux nodes, use a Linux security module such as [AppArmor](/docs/tutorials/security/apparmor/) (beta)
|
||||
or [seccomp](/docs/tutorials/security/seccomp/).
|
||||
|
||||
### Runtime protection: storage {#protection-runtime-storage}
|
||||
|
||||
To protect storage for your cluster and the applications that run there, you can:
|
||||
|
||||
1. Integrate your cluster with an external storage plugin that provides encryption at
|
||||
rest for volumes.
|
||||
1. Enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for
|
||||
API objects.
|
||||
1. Protect data durability using backups. Verify that you can restore these, whenever you need to.
|
||||
1. Authenticate connections between cluster nodes and any network storage they rely
|
||||
upon.
|
||||
1. Implement data encryption within your own application.
|
||||
|
||||
For encryption keys, generating these within specialized hardware provides
|
||||
the best protection against disclosure risks. A _hardware security module_
|
||||
can let you perform cryptographic operations without allowing the security
|
||||
key to be copied elsewhere.
|
||||
|
||||
### Networking and security
|
||||
|
||||
You should also consider network security measures, such as
|
||||
[NetworkPolicy](/docs/concepts/services-networking/network-policies/) or a
|
||||
[service mesh](https://glossary.cncf.io/service-mesh/).
|
||||
Some network plugins for Kubernetes provide encryption for your
|
||||
cluster network, using technologies such as a virtual
|
||||
private network (VPN) overlay.
|
||||
By design, Kubernetes lets you use your own networking plugin for your
|
||||
cluster (if you use managed Kubernetes, the person or organization
|
||||
managing your cluster may have chosen a network plugin for you).
|
||||
|
||||
The network plugin you choose and the way you integrate it can have a
|
||||
strong impact on the security of information in transit.
|
||||
|
||||
### Observability and runtime security
|
||||
|
||||
Kubernetes lets you extend your cluster with extra tooling. You can set up third
|
||||
party solutions to help you monitor or troubleshoot your applications and the
|
||||
clusters they are running. You also get some basic observability features built
|
||||
in to Kubernetes itself. Your code running in containers can generate logs,
|
||||
publish metrics or provide other observability data; at deploy time, you need to
|
||||
make sure your cluster provides an appropriate level of protection there.
|
||||
|
||||
If you set up a metrics dashboard or something similar, review the chain of components
|
||||
that populate data into that dashboard, as well as the dashboard itself. Make sure
|
||||
that the whole chain is designed with enough resilience and enough integrity protection
|
||||
that you can rely on it even during an incident where your cluster might be degraded.
|
||||
|
||||
Where appropriate, deploy security measures below the level of Kubernetes
|
||||
itself, such as cryptographically measured boot, or authenticated distribution
|
||||
of time (which helps ensure the fidelity of logs and audit records).
|
||||
|
||||
For a high assurance environment, deploy cryptographic protections to ensure that
|
||||
logs are both tamper-proof and confidential.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
### Cloud native security {#further-reading-cloud-native}
|
||||
|
||||
* CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
|
||||
on cloud native security.
|
||||
* CNCF [white paper](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)
|
||||
on good practices for securing a software supply chain.
|
||||
* [Fixing the Kubernetes clusterf\*\*k: Understanding security from the kernel up](https://archive.fosdem.org/2020/schedule/event/kubernetes/) (FOSDEM 2020)
|
||||
* [Kubernetes Security Best Practices](https://www.youtube.com/watch?v=wqsUfvRyYpw) (Kubernetes Forum Seoul 2019)
|
||||
* [Towards Measured Boot Out of the Box](https://www.youtube.com/watch?v=EzSkU3Oecuw) (Linux Security Summit 2016)
|
||||
|
||||
### Kubernetes and information security {#further-reading-k8s}
|
||||
|
||||
* [Kubernetes security](/docs/concepts/security/)
|
||||
* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* [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/)
|
||||
* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
|
||||
* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
|
||||
* [Network policies](/docs/concepts/services-networking/network-policies/) for Pods
|
||||
* [Pod security standards](/docs/concepts/security/pod-security-standards/)
|
||||
* [RuntimeClasses](/docs/concepts/containers/runtime-class)
|
||||
|
||||
|
|
@ -1,160 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- zparnold
|
||||
title: Overview of Cloud Native Security
|
||||
description: >
|
||||
A model for thinking about Kubernetes security in the context of Cloud Native security.
|
||||
content_type: concept
|
||||
weight: 1
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
|
||||
|
||||
{{< warning >}}
|
||||
This container security model provides suggestions, not proven information security policies.
|
||||
{{< /warning >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## The 4C's of Cloud Native security
|
||||
|
||||
You can think about security in layers. The 4C's of Cloud Native security are Cloud,
|
||||
Clusters, Containers, and Code.
|
||||
|
||||
{{< note >}}
|
||||
This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
|
||||
computing approach to security, which is widely regarded as a best practice for securing
|
||||
software systems.
|
||||
{{< /note >}}
|
||||
|
||||
{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" class="diagram-large" >}}
|
||||
|
||||
Each layer of the Cloud Native security model builds upon the next outermost layer.
|
||||
The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
|
||||
You cannot safeguard against poor security standards in the base layers by addressing
|
||||
security at the Code level.
|
||||
|
||||
## Cloud
|
||||
|
||||
In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the
|
||||
[trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
|
||||
of a Kubernetes cluster. If the Cloud layer is vulnerable (or
|
||||
configured in a vulnerable way) then there is no guarantee that the components built
|
||||
on top of this base are secure. Each cloud provider makes security recommendations
|
||||
for running workloads securely in their environment.
|
||||
|
||||
### Cloud provider security
|
||||
|
||||
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 >}}
|
||||
|
||||
### Infrastructure security {#infrastructure-security}
|
||||
|
||||
Suggestions for securing your infrastructure in a Kubernetes cluster:
|
||||
|
||||
{{< table caption="Infrastructure security" >}}
|
||||
|
||||
Area of Concern for Kubernetes Infrastructure | Recommendation |
|
||||
--------------------------------------------- | -------------- |
|
||||
Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
|
||||
Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists) from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
|
||||
Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
|
||||
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
|
||||
etcd Encryption | Wherever possible it's a good practice to encrypt all storage at rest, and since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
|
||||
|
||||
{{< /table >}}
|
||||
|
||||
## Cluster
|
||||
|
||||
There are two areas of concern for securing Kubernetes:
|
||||
|
||||
* Securing the cluster components that are configurable
|
||||
* Securing the applications which run in the cluster
|
||||
|
||||
### Components of the Cluster {#cluster-components}
|
||||
|
||||
If you want to protect your cluster from accidental or malicious access and adopt
|
||||
good information practices, read and follow the advice about
|
||||
[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/).
|
||||
|
||||
### Components in the cluster (your application) {#cluster-applications}
|
||||
|
||||
Depending on the attack surface of your application, you may want to focus on specific
|
||||
aspects of security. For example: If you are running a service (Service A) that is critical
|
||||
in a chain of other resources and a separate workload (Service B) which is
|
||||
vulnerable to a resource exhaustion attack, then the risk of compromising Service A
|
||||
is high if you do not limit the resources of Service B. The following table lists
|
||||
areas of security concerns and recommendations for securing workloads running in Kubernetes:
|
||||
|
||||
Area of Concern for Workload Security | Recommendation |
|
||||
------------------------------ | --------------------- |
|
||||
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
|
||||
Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/
|
||||
Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
Ensuring that pods meet defined Pod Security Standards | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
|
||||
Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
|
||||
Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
|
||||
TLS for Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
|
||||
|
||||
## Container
|
||||
|
||||
Container security is outside the scope of this guide. Here are general recommendations and
|
||||
links to explore this topic:
|
||||
|
||||
Area of Concern for Containers | Recommendation |
|
||||
------------------------------ | -------------- |
|
||||
Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
|
||||
Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
|
||||
Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
|
||||
Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation.
|
||||
|
||||
## Code
|
||||
|
||||
Application code is one of the primary attack surfaces over which you have the most control.
|
||||
While securing application code is outside of the Kubernetes security topic, here
|
||||
are recommendations to protect application code:
|
||||
|
||||
### Code security
|
||||
|
||||
{{< table caption="Code security" >}}
|
||||
|
||||
Area of Concern for Code | Recommendation |
|
||||
-------------------------| -------------- |
|
||||
Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual TLS authentication or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
|
||||
Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
|
||||
3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
|
||||
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
|
||||
Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://www.zaproxy.org/) tool. |
|
||||
|
||||
{{< /table >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn about related Kubernetes security topics:
|
||||
|
||||
* [Pod security standards](/docs/concepts/security/pod-security-standards/)
|
||||
* [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
|
||||
* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
|
||||
* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* [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/)
|
||||
* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
|
||||
* [Runtime class](/docs/concepts/containers/runtime-class)
|
||||
|
|
@ -5,7 +5,7 @@ title: Pod Security Standards
|
|||
description: >
|
||||
A detailed look at the different policy levels defined in the Pod Security Standards.
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 15
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Service Accounts
|
|||
description: >
|
||||
Learn about ServiceAccount objects in Kubernetes.
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 25
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -547,10 +547,13 @@ other="""Third party content advice"""
|
|||
|
||||
[thirdparty_message_single_item]
|
||||
other = """🛇 This item links to a third party project or product that is not part of Kubernetes itself. <a class="alert-more-info" href="#third-party-content-disclaimer">More information</a>"""
|
||||
|
||||
[thirdparty_message_disclaimer]
|
||||
other = """<p>Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">CNCF website guidelines</a> for more details.</p><p>You should read the <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> before proposing a change that adds an extra third-party link.</p>"""
|
||||
|
||||
[thirdparty_message_vendor]
|
||||
other = """Items on this page refer to vendors external to Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. To add a vendor, product or project to this list, read the <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> before submitting a change. <a href="#third-party-content-disclaimer">More information.</a>"""
|
||||
|
||||
|
||||
[ui_search_placeholder]
|
||||
other = "Search this site"
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,13 @@
|
|||
{{- $single := .Get "single" | default "false" -}}
|
||||
{{- $vendor_message := .Get "vendor" | default "false" -}}
|
||||
<div class="alert alert-secondary callout third-party-content" role="alert">
|
||||
{{- if not (eq $single "true" ) -}}
|
||||
<strong>{{ T "note" | safeHTML }}</strong>
|
||||
{{ T "thirdparty_message" | safeHTML }}
|
||||
{{- if (eq $vendor_message "true" ) -}}
|
||||
{{ T "thirdparty_message_vendor" | safeHTML }}
|
||||
{{- else -}}
|
||||
{{ T "thirdparty_message" | safeHTML }}
|
||||
{{- end -}}
|
||||
{{- else -}}
|
||||
{{ T "thirdparty_message_single_item" | safeHTML }}
|
||||
{{- end -}}
|
||||
|
|
|
|||
|
|
@ -201,6 +201,7 @@
|
|||
|
||||
/docs/reporting-security-issues/ /docs/reference/issues-security/security/ 301
|
||||
/security/ /docs/reference/issues-security/security/ 302
|
||||
/docs/concepts/security/overview/ /docs/concepts/security/ 301
|
||||
|
||||
/docs/roadmap/ https://github.com/kubernetes/kubernetes/milestones/ 301
|
||||
/docs/samples/ /docs/tutorials/ 301
|
||||
|
|
|
|||
Loading…
Reference in New Issue