kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #21493 from kbhawkey/kb-security-overview-cleanup 

modify security overview
This commit is contained in:
Kubernetes Prow Robot 2020-06-12 21:57:57 -07:00 committed by GitHub
parent 9aca67c4a1 6820d60f04
commit edafb080e6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 75 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

161
content/en/docs/concepts/security/overview.md
View File

@ -3,59 +3,53 @@ reviewers:
- zparnold
title: Overview of Cloud Native Security
content_type: concept
weight: 1
weight: 10
---
{{< toc >}}
<!-- overview -->
Kubernetes Security (and security in general) is an immense topic that has many
highly interrelated parts. In today's era where open source software is
integrated into many of the systems that help web applications run,
there are some overarching concepts that can help guide your intuition about how you can
think about security holistically. This guide will define a mental model
for some general concepts surrounding Cloud Native Security. The mental model is completely arbitrary
and you should only use it if it helps you think about where to secure your software
stack.
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
Let's start with a diagram that may help you understand how you can think about security in layers.
## 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))
approach to security, which is widely regarded as a best practice for securing
software systems. The 4C's are Cloud, Clusters, Containers, and Code.
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" >}}
As you can see from the above figure,
each one of the 4C's depend on the security of the squares in which they fit. It
is nearly impossibly to safeguard against poor security standards in Cloud, Containers, and Code
by only addressing security at the code level. However, when these areas are dealt
with appropriately, then adding security to your code augments an already strong
base. These areas of concern will now be described in more detail below.
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 these components themselves are vulnerable (or
configured in a vulnerable way) then there's no real way to guarantee the security
of any components built on top of this base. Each cloud provider has extensive
security recommendations they make to their customers on how to run workloads securely
in their environment. It is out of the scope of this guide to give recommendations
on cloud security since every cloud provider and workload is different. Here are some
links to some of the popular cloud providers' documentation
for security as well as give general guidance for securing the infrastructure that
makes up a Kubernetes cluster.
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 Table
### 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 |
-------------------- | ------------ |
@ -66,46 +60,48 @@ IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
{{< /table >}}
If you are running on your own hardware or a different cloud provider you will need to
consult your documentation for security best practices.
### Infrastructure security {#infrastructure-security}
### General Infrastructure Guidance Table
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 (Masters) | Ideally all access to the Kubernetes Masters 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 (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters 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 will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. 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. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
--------------------------------------------- | -------------- |
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 drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
{{< /table >}}
## Cluster
This section will provide links for securing
workloads in Kubernetes. There are two areas of concern for securing
Kubernetes:
There are two areas of concern for securing Kubernetes:
* Securing the components that are configurable which make up the cluster
* Securing the components which run in the cluster
* Securing the cluster components that are configurable
* Securing the applications which run in the cluster
### Components of the Cluster {#cluster-components}
### Components _of_ the Cluster
If you want to protect your cluster from accidental or malicious access, and adopt
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)
### 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
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, by not putting resource limits on
Service B you run the risk of also compromising Service A. Below is a table of
links of things to consider when securing workloads running in Kubernetes.
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/reference/access-authn-authz/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/
@ -114,52 +110,45 @@ Quality of Service (and Cluster resource management) | https://kubernetes.io/doc
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
In order to run software in Kubernetes, it must be in a container. Because of this,
there are certain security considerations that must be taken into account in order
to benefit from the workload security primitives of Kubernetes. Container security
is also outside the scope of this guide, but here is a table of general
recommendations and links for further exploration of this topic.
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 or on a regular basis you should scan your containers for known vulnerabilities with a tool such as [CoreOS's Clair](https://github.com/coreos/clair/)
Image Signing and Enforcement | Two other CNCF Projects (TUF and Notary) are useful tools for signing container images and maintaining a system of trust for the content of your containers. If you use Docker, it is built in to the Docker Engine as [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/). On the enforcement piece, [IBM's Portieris](https://github.com/IBM/portieris) project is a tool that runs as a Kubernetes Dynamic Admission Controller to ensure that images are properly signed via Notary before being admitted to the Cluster.
------------------------------ | -------------- |
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.
## Code
Finally moving down into the application code level, this is one of the primary attack
surfaces over which you have the most control. This is also outside of the scope
of Kubernetes but here are a few recommendations:
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:
### General Code Security Guidance Table
### Code security
{{< table caption="Code security" >}}
Area of Concern for Code | Recommendation |
--------------------------------------------- | ------------ |
Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). |
-------------------------| -------------- |
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 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 | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each 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 here: https://owasp.org/www-community/Source_Code_Analysis_Tools |
Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://owasp.org/www-project-zap/ |
## Robust automation
Most of the above mentioned suggestions can actually be automated in your code
delivery pipeline as part of a series of checks in security. To learn about a
more "Continuous Hacking" approach to software delivery, [this article](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/) provides more detail.
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://owasp.org/www-project-zap/) tool. |
{{< /table >}}
## {{% heading "whatsnext" %}}
* Read about [network policies for Pods](/docs/concepts/services-networking/network-policies/)
* Read about [securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* Read about [API access control](/docs/reference/access-authn-authz/controlling-access/)
* Read about [data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Read about [data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
* Read about [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
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/)
* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* [API access control](/docs/reference/access-authn-authz/controlling-access/)
* [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/)