whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fixup security overview

Browse Source
This commit is contained in:
Karen Bradshaw
2020-06-04 15:39:31 -04:00
parent d4f302e848
commit 6820d60f04
1 changed files with 75 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/security/overview.md
+75 -86
View File
@@ -3,59 +3,53 @@ reviewers:
- zparnold - zparnold
title: Overview of Cloud Native Security title: Overview of Cloud Native Security
content_type: concept content_type: concept
weight: 1 weight: 10
--- ---
{{< toc >}}
<!-- overview --> <!-- 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 --> <!-- body -->
## The 4C's of Cloud Native Security ## 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.
You can think about security in layers. The 4C's of Cloud Native security are Cloud,
Clusters, Containers, and Code.
{{< note >}} {{< note >}}
This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 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 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. software systems.
{{< /note >}} {{< /note >}}
{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}} {{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}}
Each layer of the Cloud Native security model builds upon the next outermost layer.
As you can see from the above figure, The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
each one of the 4C's depend on the security of the squares in which they fit. It You cannot safeguard against poor security standards in the base layers by addressing
is nearly impossibly to safeguard against poor security standards in Cloud, Containers, and Code security at the Code level.
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.
## Cloud ## Cloud
In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the 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) [trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
of a Kubernetes cluster. If these components themselves are vulnerable (or of a Kubernetes cluster. If the Cloud layer is vulnerable (or
configured in a vulnerable way) then there's no real way to guarantee the security configured in a vulnerable way) then there is no guarantee that the components built
of any components built on top of this base. Each cloud provider has extensive on top of this base are secure. Each cloud provider makes security recommendations
security recommendations they make to their customers on how to run workloads securely for running workloads securely in their environment.
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.
### 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 | 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 | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | 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 ### Infrastructure security {#infrastructure-security}
consult your documentation for security best practices.
### General Infrastructure Guidance Table Suggestions for securing your infrastructure in a Kubernetes cluster:
{{< table caption="Infrastructure security" >}}
Area of Concern for Kubernetes Infrastructure | Recommendation | 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 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 (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. 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 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 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 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 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. 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 ## Cluster
This section will provide links for securing There are two areas of concern for securing Kubernetes:
workloads in Kubernetes. There are two areas of concern for securing
Kubernetes:
* Securing the components that are configurable which make up the cluster * Securing the cluster components that are configurable
* Securing the components which run in the cluster * 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 good information practices, read and follow the advice about
[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/). [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 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 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 vulnerable to a resource exhaustion attack then the risk of compromising Service A
Service B you run the risk of also compromising Service A. Below is a table of is high if you do not limit the resources of Service B. The following table lists
links of things to consider when securing workloads running in Kubernetes. areas of security concerns and recommendations for securing workloads running in Kubernetes:
Area of Concern for Workload Security | Recommendation | Area of Concern for Workload Security | Recommendation |
------------------------------ | ------------ | ------------------------------ | --------------------- |
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ 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/ 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/ 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/ Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
## Container ## Container
In order to run software in Kubernetes, it must be in a container. Because of this, Container security is outside the scope of this guide. Here are general recommendations and
there are certain security considerations that must be taken into account in order links to explore this topic:
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.
Area of Concern for Containers | Recommendation | 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/) 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 | 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. 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. 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 ## Code
Finally moving down into the application code level, this is one of the primary attack Application code is one of the primary attack surfaces over which you have the most control.
surfaces over which you have the most control. This is also outside of the scope While securing application code is outside of the Kubernetes security topic, here
of Kubernetes but here are a few recommendations: are recommendations to protect application code:
### General Code Security Guidance Table ### Code security
{{< table caption="Code security" >}}
Area of Concern for Code | Recommendation | 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. | 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. | 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 here: https://owasp.org/www-community/Source_Code_Analysis_Tools | 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 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/ | 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. |
## 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.
{{< /table >}}
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* Read about [network policies for Pods](/docs/concepts/services-networking/network-policies/) Learn about related Kubernetes security topics:
* 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/)
* [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/)