从0到1使用Kubernetes系列(八):Kubernetes安全
本文是从 0 到 1 使用 Kubernetes 系列第八篇,上一篇从0到1使用Kubernetes系列(七):网络介绍了 K8S 网络相关的内容,本文将带你了解 K8S 的安全问题。
Kubernetes 的安全是一个相当广泛的主题,涉及很多高度相关的内容。和探讨大部分安全性相关的问题一样,首先需要考虑威胁模型——谁可能攻击你的系统,以及他们如何做到这一点。这可以帮你确定安全工作的优先级。对于大多数 Kubernetes 应用有三类主要的攻击者:
- 外部攻击者:当你在内部或云上部署应用时,你可能面临来自集群外的攻击。这类攻击者没有系统权限,所以会专注于公开的服务,会尝试获取访问权限并提升权限。
- 泄露的容器:Kubernetes 集群通常运行着各种工作负载。攻击者也可能利用集群中运行的容器的漏洞进行攻击,在这种时候,要最大程度降低漏洞攻击影响到整个集群的风险。攻击者可以访问单个容器的资源,因此限制容器权限至关重要。
- 恶意用户:Kubernetes 是一个多用户系统。攻击者可能拥有某用户的账户,并企图获得更多权限,这种情况比较复杂,要具体分析,需要限制不同用户的访问权限。
围绕云原生基础概念构建的模型可以帮你建立对 Kubernetes 安全的总体认识。下图将安全划分为四个层级,被称为云原生安全的4C模型。管理员将在不同的层次上应对三类攻击者。
4C 指的是云(Cloud)、集群(Cluster),容器(Containers)和代码(Code)
正如你在图中所看见的,4C 模型中每部分的安全性都是相互包含的。只依靠增强代码层次安全来预防云、集群和容器中安全漏洞是几乎不可能的。适当提高其他层的安全能力,就已经为你的代码提供强大的基础安全保障。下面将详细介绍这四部分内容。
Cloud
大多数情况下,云为 Kubernetes 集群提供可信的计算资源。如果云的基础设置是不可靠的(或以易受到攻击的方式配置),那就没有办法保证在这个基础上构建的 Kubernetes 集群的安全性。每一个云服务提供商都向他们的客户提供大量如何在其环境安全运行负载的建议。下面提供常用云服务厂商的安全文档链接,并且提供了构建安全 Kubernetes 集群的建议。
云服务提供商安全文档列表
云服务厂商 | 链接 |
---|---|
阿里云 | https://www.alibabacloud.com/trust-center |
AWS | https://aws.amazon.com/security/ |
Google Cloud Platform | https://cloud.google.com/security/ |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
如果你运行在自己的硬件上或者其他云服务提供商,请查阅文档获取最佳安全实践。
通用的安全建议
理想情况下,不开放 Kubernetes Master 节点公网访问,并且限制能够访问集群 Master 节点的 IP 地址。
通过网络安全组等配置工作节点只接受 Master 节点上指定端口的连接,并且接受 Kubernetes 中服务类型为 NodePort 和 LoadBalancer 的连接。如果可能,这些节点也不应该暴露在公网中。
Kubernetes 访问云服务提供商的 API,每一个云服务提供商都赋予 Kubernetes 的 Master 和 Node 不同的权限。该访问权限遵循其管理资源所需资源的最小权限原则。
访问 etcd, 只有在 master 节点中通过 TLS 可以访问 etcd。
在所有可能情况下,对停用状态的的驱动设备加密。ectd 拥有整个集群的状态(包括密钥信息),因此对其磁盘要在其停用的时候加密。
Cluster
Kubernetes 是一个复杂的系统,下图展示了一个集群不同的组成部分,为了保证集群整体的安全,需要仔细保护每一个组件。
将需要注意保护的集群组件划分成两个部分:
- 保护组成集群的可配置组件
- 保护运行在集群中的应用
集群的组件
控制对 Kubernetes API 的访问
使用 TLS 进行安全通讯。Kubernetes 期望默认情况下使用 TLS 对集群中所有 API 通信进行加密,大多数安装方式都会创建必要的证书并分发给集群组件。
API 认证。在安装集群时,为API服务器选择与通用访问模式匹配的身份验证机制。例如,小型单用户集群可能希望使用简单的证书或静态Bearer令牌方法。较大的群集可能希望集成现有的OIDC或LDAP服务器,以将用户细分为多个组。更多有信息请参考认证。
API 授权。一旦通过身份验证,每个API调用也都有望通过授权检查。Kubernetes 附带了一个集成的基于角色的访问控制(RBAC)组件,该组件将传入的用户或组与捆绑到角色中的一组权限进行匹配。这些权限将动词(get,create,delete)与资源(pods,service,nodes)结合在一起,并且可以是命名空间或集群作用域。提供了一组现成的角色,这些角色根据客户端可能要执行的操作提供合理的默认责任分离。更多有关信息请参考授权
控制对 Kubelet 的访问。
Kubelet 在端口10250和10255上提供小型 REST API。端口10250是读/写端口,而10255是具有API端点子集的只读端口。这些端点授予对节点和容器的强大控制权。默认情况下,Kubelets允许未经身份验证对此API进行访问。生产集群应启用 Kubelet 身份验证和授权,可以通过设置
--read-only-port=0
来禁用只读端口,但是10250 端口用于系统指标收集和其他重要功能,所以开发者必须仔细控制对此端口的访问。更多有关信息请参考Kubelet身份验证/授权保护集群组件不受损坏
- 限制对 etcd 的访问。对API的etcd后端的写入访问权等同于在整个集群上获得root权限,而读取访问权也可以获取集群信息。管理员应始终使用从API服务器到etcd服务器的强凭据,例如通过TLS客户端证书的相互身份验证,通常建议 etcd服务器隔离在仅API服务器可以访问的防火墙后面。
- 限制对Alpha或Beta功能的访问。Alpha和Beta Kubernetes功能正在积极开发中,并且可能会存在限制或错误,从而导致安全漏洞。始终评估Alpha或Beta功能可能提供的价值,以防对您的安全状况造成潜在风险。如有疑问,请禁用不使用的功能。
- 启用审核日志记录。审核记录器是一项Beta版功能,可记录API的行为,在出现问题后提供分析依据。
- 经常轮换基础设施凭证。密钥和凭证生存周期越短,就越难被攻击者利用。
- 在启用第三方集成之前,请先进行审查。
- 停用时加密 ectd。etcd数据库将包含可通过Kubernetes API访问的所有信息,可能使攻击者深入了解群集的状态。
- 接收有关安全更新和报告漏洞的警报。
集群中的应用
根据应用程序受到的攻击,关注安全的特定方面。例如,运行中的服务 A 对于其他应用非常重要,而服务 B 容易受到资源耗尽攻击,如果不设置服务 B 的资源限制,就会因为服务 B 耗尽资源导致服务 A 不可用。所以需要注意下面几个常见安全措施:
定义资源限制
默认情况下,Kubernetes 集群中对所有资源没有对 CPU 、内存和磁盘的使用限制。可以通过创建资源配额策略,并附加到 namespace 中来限制资源的使用。
下面的例子将限制命名空间中Pod 的数量为4个,CPU使用在1和2之间,内存使用在1GB 和 2GB 之间。
# compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4"
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
requests.nvidia.com/gpu: 4
分配资源配额到命名空间:
kubectl create -f ./compute-resources.yaml --namespace=myspace
查看 namespace 资源使用情况:
[root@localhost ~]# kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
requests.nvidia.com/gpu 0 4
也可以为 Pod 添加资源限制,设置内存请求为 256MiB,内存限制为512MiB
```yaml apiVersion: v1 kind: Pod metadata: name: default-mem-demo spec: containers:
- name: default-mem-demo-ctr image: nginx resources: limits: memory: 512Mi requests: memory: 256Mi ```
Pod 安全策略
作为 Pod 的组成部分,容器通常配置有非常实用的安全默认值,这些默认值适用于大多数情况。但是,有时 Pod 可能需要其他权限才能执行其预期任务,在这种情况下,我们需要增强 Pod 的默认权限。安全上下文定义了 Pod 或容器的特权和访问控制,安全上下文设置有:
- 委托访问:基于用户ID 和用户组ID 权限去访问资源对象(如文件)。
- SELinux:为对象分配安全标签
- 以特权或非特权用户运行
- Linux 功能:为进程提供一些特权,而不去赋予它root用户的所有特权
- AppArmor:使用程序配置文件来限制单个程序的功能。
- Seccomp:过滤进程的系统调用
- 允许提升权限(AllowPrivilegeEscalation):子进程能否获得父进程更多的权限。这个布尔值直接控制是否在容器进程上设置了 no_new_privs 标志。在以下情况下 AllowPrivilegeEscalation 始终为 true——一是,以特权OR运行;二是,具有
CAP_SYS_ADMIN
。
在
securityContext
字段下配置安全策略,在 Pod 中指定的安全策略将被应用于所有容器,容器中指定的安全策略应用于单个容器,当它们重复时,容器级会覆盖 Pod 级的的安全策略。apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
更多有关信息请参考Pod 安全策略
网络规则
Kubernetes允许来自集群中任何容器的所有网络流量发送到集群中的任何其他容器并由其接收。当尝试隔离工作负载时,这种开放式方法没有帮助,因此需要应用网络策略来帮助开发者实现所需的隔离。Kubernetes NetworkPolicy API使开发者能够将入口和出口规则应用于选定的Pod,用于第3层和第4层流量,并依赖于实现容器网络接口(CNI)的兼容网络插件的部署。
网络策略是 namespace 作用域,并根据匹配标签(例如,tier:backend)的选择应用于Pod。当NetworkPolicy对象的Pod选择器与Pod匹配时,根据策略中定义的入口和出口规则来管理进出Pod的流量。 所有来自或发往该Pod的流量都会被拒绝,除非有允许它的规则。
要在Kubernetes集群中正确隔离网络和传输层的应用程序,网络策略应以“拒绝所有”的默认前提开始。然后,应将每个应用程序组件及其所需源和目标的规则逐个列入白名单,并进行测试以确保流量模式按预期工作。
密钥管理
Kubernetes 使用 Secrets 保护应用程序需要访问敏感信息——密码、X.509证书、SSH密钥或OAuth令牌等。它通过卷装入,对它的访问严格限于那些需要使用它的实体(用户和Pod),且当存储在磁盘上时(静止状态)它是不可访问或只读的。
需要考虑的全部安全问题如下:
Contanier
为了在 Kunernetes 中运行软件,必须将它打包成容器。需要考虑下面的注意事项,来保证容器符合 Kubernetes 安全配置。
最小化镜像
理想情况下,使用应用程序二进制文件和二进制文件所依赖的的任何相关项来创建镜像。事实上,没有什么阻止开发者将
scratch
作为基础镜像,并将静态链接的二进制文件复制到镜像中。它没有其他依赖,镜像中包含单个文件,以及一些描述容器如何运行的元数据。最小化镜像加快镜像的分发速度,并且显著减少容器内部的受攻击面。基础镜像
但是这并不总是可行的,因此需要慎重选择基础镜像。最佳的方法是使用操作系统供应商支持的镜像,或者是 docker hub 上官方支持的镜像。不要盲目使用之前未经过审查的不受信任来源的镜像,尤其是在生产环境中。
镜像扫描
镜像扫描对于保障容器应用的安全至关重要,确保您的镜像定期通过信誉良好的工具进行扫描,可以使用 CoreOS 的 Clair 之类的工具扫描容器中的已知漏洞,它是容器镜像的静态漏洞分析器。
镜像的签名和执行
使用 CNCF 项目的的 TUF 和 Notary 对容器进行签名,在执行前验证签名,确保镜像的正确没有被篡改。
禁止特权用户
在构建镜像时,创建最低操作系统权限的用户完成容器的运行。
Code
最后是代码级别,这是程序员能掌控的被攻击面,但不在 Kubernetes 的安全保护范围,提供如下建议:
仅通过 TLS 访问
如果您的代码需要通过TCP进行通信,则理想情况下,它将提前与客户端执行TLS握手。除少数情况外,默认行为应是对传输中的所有内容进行加密。
限制通信范围
无论什么情况下,程序只应该公开必要的端口。
第三方依赖安全性
确保第三方依赖是安全的。
静态代码分析
大多数语言都提供了静态代码分析,可以分析代码中是否存在潜在的不安全编码实践。
动态探测攻击
自动化工具可以针对您的服务尝试会破坏服务的攻击。这些包括SQL注入,CSRF和XSS。最受欢迎的动态分析工具之一是OWASP Zed Attack代理。
本文由猪齿鱼技术团队原创,转载请注明出处
从0到1使用Kubernetes系列(八):Kubernetes安全的更多相关文章
- Kubernetes系列02—Kubernetes设计架构和设计理念
本文收录在容器技术学习系列文章总目录 1.Kubernetes设计架构 Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc),一切都基于分 ...
- Docker系列(八)Kubernetes介绍
Kubernetes组件功能图 各组件说明: 节点 节点在Kubernetes由虚拟机或者实体机表示,常称为Minion,即从属主机.当一个节点加入到Kubernetes系统中时,它将会创建一个数 ...
- kubernetes系列06—kubernetes资源清单定义入门
本文收录在容器技术学习系列文章总目录 1.认识kubernetes资源 1.1 常用资源/对象 workload工作负载型资源:pod,ReplicaSet,Deployment,StatefulSe ...
- Kubernetes系列:Kubernetes Dashboard
15.1.Dashboard 作为Kube认得Web用户界面,用户可以通过Dashboard在Kubernetes集群中部署容器化的应用,对应用进行问题处理和管理,并对集群本身进行管理.通过Dashb ...
- 从0到1使用Kubernetes系列(二):安装工具介绍
该系列第一篇为:<从0到1使用Kubernetes系列--Kubernetes入门>.本文是Kubernetes系列的第二篇,将介绍使用Kubeadm+Ansible搭建Kubernete ...
- 从0到1使用Kubernetes系列(六):数据持久化实战
本文是从 0 到 1 使用 Kubernetes 系列第六篇,上一篇<从 0 到 1 使用 Kubernetes 系列(五):Kubernetes Scheduling>介绍了 Kuber ...
- 从0到1使用Kubernetes系列(七):网络
本文是从 0 到 1 使用 Kubernetes 系列第七篇,上一篇<从 0 到 1 使用 Kubernetes 系列(六):数据持久化实战> 介绍了 Kubernetes 中的几种常用储 ...
- Kubernetes 系列(八):搭建EFK日志收集系统
Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch.Fluentd 和 Kibana(EFK)技术栈,也是官方现在比较推荐的一种方案. Elasticsearch 是一个 ...
- 从0到1使用Kubernetes系列——Kubernetes入门
基本概念 Docker 是什么 Docker 起初是 dotCloud 公司创始人 Solomon Hykes 在法国的时候发起的一项公司内部项目,Docker 是基于 dotCloud 公司多年云服 ...
随机推荐
- 如何基于Jupyter notebook搭建Spark集群开发环境
摘要:本文介绍如何基于Jupyter notebook搭建Spark集群开发环境. 本文分享自华为云社区<基于Jupyter Notebook 搭建Spark集群开发环境>,作者:apr鹏 ...
- 无法解析的外部符号之_cvLoadImage,_cvCreateMat,_cvReleaseImage之类
一个错误可能是:附加依赖项少添加了库函数: 还有一个可能是:配置设置错误了,比如该是64位,却设置成win32了.改过来就好了. 要注意opencv的使用中 在Debug.Release模式以及x64 ...
- nGrinder 参数使用
背景: 性能测试中为了更加接近真实模拟现实应用,对于提交的信息每次都需要提交不同的数据,或使用不同的值,最为典型的就是登录时的账号. 性能测试工具需要提供动态参数化功能,如商业化的LoadRunner ...
- opencv中的exp32f函数
exp32f opencv的exp函数和cmath的exp函数在精度上存在一定差异,通过查找源码,发现了这么一段实现.代码如下: 点击查看代码 #define EXPTAB_SCALE 6 #defi ...
- 2020.11.6-vj补题
A - A CodeForces - 136A 题解:按输入的顺序输出对应的下标即可,定义一个数组,将输入的作为下标,下标为值,最后依次输出即可: #include<bits/stdc++.h& ...
- clock时钟
①时钟的偏移(skew):时钟分支信号在到达寄存器的时钟端口过程中,都存在有线网等延时,由于延时,到达寄存器时钟端口的时钟信号存在有相位差,也就是不能保证每一个沿都对齐,这种差异称为时钟偏移(cloc ...
- el-scrollbar滚动条置底
<el-scrollbar ref="leftScrollbar" style="height: 600px"></el-scrollbar& ...
- 【UE4 C++ 基础知识】<8> Delegate 委托
概念 定义 UE4中的delegate(委托)常用于解耦不同对象之间的关联:委托的触发者不与监听者有直接关联,两者通过委托对象间接地建立联系. 监听者通过将响应函数绑定到委托上,使得委托触发时立即收到 ...
- 第二次Scrum Metting
日期:2021年4月25日会议主要内容概述:前后端针对WebAPI进行协调与统一工作,商量接下来两日计划:敲定部分设计细节. 一.进度情况 组员 负责 两日内已完成的工作 后两日计划完成的工作 工作中 ...
- spring security整合QQ登录
最近在了解第三方登录的内容,尝试对接了一下QQ登录,此次记录一下如何实现QQ登录的过程,在这个例子中是和spring secuirty整合的,不整合spring secuirty也是一样的. 需求: ...