Kubernetes的打包工具Helm Helm有两个重要的概念:chart和release。 chart是创建一个应用的信息集合,包括各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等。chart是应用部署的自包含逻辑单元。 当chart被安装到Kubernetes集群,就生成一个release。chart能够多次安装到同一个集群,每次安装都是一个release。 安装部署Helm curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get|bash 创建补全 helm completion -clusterrole=cluster-kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{" 结果如图11
Kubernetes 近期爆出两个中级安全漏洞: CVE-2020-8551 CVE-2020-8552 以下为Kubernetes 安全漏洞的说明。 ? Kubernetes上述漏洞在CVSS评级为中等级别,安全风险为DoS攻击。 “未来五年,是kubernetes的黄金五年。” 在这个黄金五年,CNCF组织依托kubernetes等开源项目推进现代云原生的发展,构建现代软件开发技术栈。 ? CVE-2020-8552 说明 攻击者方通过授权的API请求对Kubernetes API Server服务进行拒绝服务攻击。 /kubernetes/issues/89377 [3] https://github.com/kubernetes/kubernetes/issues/89378
• K8S安全控制框架主要由下面3个阶段进行控制,每一个阶段都 支持插件方式,通过API Server配置来启用插件。 :RBAC RBAC(Role-Based Access Control,基于角色的访问控 制),允许通过Kubernetes API动态配置策略。 /pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -config=ca-config.json -profile=kubernetes zpj-csr.json Labels: <none> Annotations: kubernetes.io/service-account.name: dashboard-admin kubernetes.io/service-account.uid: fdf94e5a-5b5f-4d40-95d9-4cb5d2409991 Type: kubernetes.io/service-account-token
机制说明 Kubernetes 作为一个分布式集群的管理工具,保证集群的安全性是其一个重要的任务。API Server 是集群内部 各个组件通信的中介,也是外部控制的入口。 所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计 的。 若无法正常加载, 请点击查看 PDF 网页版本: Kubernetes 集群安全 - 机制说明.pdf 2. 默认挂载目录: /run/secrets/kubernetes.io/serivceaccount 总结 若无法正常加载, 请点击查看 PDF 网页版本: Kubernetes 集群安全 - 认证 若无法正常加载, 请点击查看 PDF 网页版本: Kubernetes 集群安全 - 准入控制.pdf
这两天在梳理Kubernetes集群的安全配置,涉及到各个组件的配置,最终决定画一个图来展现,应该会更清晰。 /dd_ca.crt --tls-private-key-file=/var/run/kubernetes/dd_server.key ``` kube-controller-manager name: my-context current-context: my-context ``` kube-scheduler kube-scheduler访问apiserver的安全配置同 /serviceaccount/token /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /var/run/secrets/kubernetes.io apiserver了: - 添加kubectl proxy container,示例见[kubectl-container](https://github.com/kubernetes/kubernetes
Kubernetes 安全机制解读 在 k8s 中,所有资源的访问和变更都是围绕 APIServer 展开的。 比如说 kubectl 命令、客户端 HTTP RESTFUL 请求,都是去 call APIServer 的 API 进行的,本文就重点解读 k8s 为了集群安全,都做了些什么。 ? Kubernetes 官方文档给出了上面这张图,描述了用户在访问或变更资源的之前,需要经过 APIServer 的认证机制、授权机制以及准入控制机制。 值得一提的是,Kubernetes 已经内置了很多个为系统保留的 ClusterRole,它们的名字都以 system: 开头。 这一层安全检查的意义在于,检查该请求是否达到系统的门槛,即是否满足系统的默认设置,并添加默认参数。
一、访问控制概述 Kubernetes作为一个分布式集群的管理工具,保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 二、认证管理 Kubernetes集群安全的最关键点在于如何识别并认证客户端身份,它提供了3种客户端身份认证方式: HTTP Base认证:通过用户名+密码的方式认证 这种认证方式是把“用户名 HTTPS证书认证:基于CA根证书签名的双向数字证书认证方式 这种认证方式是安全性最高的一种方式,但是同时也是操作起来最麻烦的一种方式。 @kubernetes Switched to context "kubernetes-admin@kubernetes". 设置默认的“容忍”时间,为5min PodSecurityPolicy:这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制
一旦装好了kubernetes,登录master之后就有了足够的权限 如果想在worker节点上运行并查看集群状态怎么办? kubectl get csr NAME AGE SIGNERNAME REQUESTOR CONDITION john 27s kubernetes.io /legacy-unknown kubernetes-admin Pending [root@vms61 xx]# kubectl get csr NAME AGE SIGNERNAME REQUESTOR CONDITION john 37s kubernetes.io/legacy-unknown kubernetes-admin /legacy-unknown kubernetes-admin Approved,Issued 一旦审批之后,k8s暂且还没有提供任何撤销这个功能 图片7.png [root@vms61
(5).参考资料 1.kubernetes从入门到精通 https://www.kancloud.cn/huyipow/kubernetes/716441
9000:9000 删除ns export NAMESPACE=devops kubectl get namespace $NAMESPACE -o json > tmp.json sed -i '/kubernetes
一、简介 笔者最近在研究容器安全时读到一本关于讲述Kubernetes安全的书籍,作者为LizRice和Michael Hausenbla,两位分别来自美国容器安全厂商Aqua和云服务厂商AWS,并在容器安全研究领域上拥有丰富的软件开发 由上图可以看出,核心章节主要对Kubernetes认证、授权、容器镜像安全、容器运行时安全、密钥管理、编排工具自身安全这六部分进行了详细说明,最后一章针对Kubernetes生态中涉及的监控、告警、审计等安全部分也进行了相应介绍 本书基本涵盖了Kubernetes安全的各个方面,下面我们首先介绍Kubernetes攻击模型。 由上图【5】不难发现,从漏洞增长率上来说, Kubernetes漏洞每年呈上升趋势,在2019年更是曝出多达11个漏洞【6】,其中中危漏洞6个,低危漏洞5个;从漏洞类型上来说,出现频次最高的为敏感信息泄露漏洞 本书作者从安全的角度给读者系统的介绍了使用Kubernetes时可能存在的安全问题及如何进行防护,内容几乎覆盖了Kubernetes的方方面面,对于想了解Kubernetes安全的人而言,本书是非常好的一本入门书籍
前言 对于大部分 Kubernetes 用户来说,安全是无关紧要的,或者说没那么紧要,就算考虑到了,也只是敷衍一下,草草了事。 实际上 Kubernetes 提供了非常多的选项可以大大提高应用的安全性,只要用好了这些选项,就可以将绝大部分的攻击抵挡在门外。 通过使用 runtime/default 注释或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault,可以轻松地在 Kubernetes 中应用默认值。 2020-11-30 知乎热议:计算机专业钱景究竟如何? 2020-11-29 VS Code有哪些奇技淫巧? 2020-11-29 API网关是否真的起到了它该有的作用? 2020-11-28 18香警告:一个女生勿近的邪恶开源项目... 2020-11-28 ﹀ ﹀ ﹀ 深度内容 推荐加入
前言 对于大部分 Kubernetes 用户来说,安全是无关紧要的,或者说没那么紧要,就算考虑到了,也只是敷衍一下,草草了事。 实际上 Kubernetes 提供了非常多的选项可以大大提高应用的安全性,只要用好了这些选项,就可以将绝大部分的攻击抵挡在门外。 对于 Kubernetes 来说,大多数容器运行时都提供一组允许或不允许的默认系统调用。 通过使用 runtime/default 注释或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault,可以轻松地在 Kubernetes 中应用默认值。 提供了非常多的选项来增强集群的安全性,没有一个放之四海而皆准的解决方案,所以需要对这些选项非常熟悉,以及了解它们是如何增强应用程序的安全性,才能使集群更加稳定安全。
实施 DevSecOps的工程团队实践和自动化安全工具将更早发现安全风险,节省开发人员时间,加快发布周期,并交付更安全和合规的代码。 组织需要一种结构化的方法,让领导者参与进来、动员安全拥护者,并确保“安全”成为“完成的定义”不可或缺的一部分。 此外,通过确保工程、安全和运营之间的一致性,鼓励开发人员“提高技能”,并专注于学习和实施有助于提高 Web 应用程序安全性的技术,更重要的是,使团队能够更早地转移安全性进入设计和编码阶段。 OWASP Top 10 鼓励将安全性集成到 CI/CD 管道、参数化查询、验证所有输入、实施错误处理、改进日志记录策略、利用安全框架的优势、保护静态数据和加密、减少敏感数据暴露等准则,实施安全访问控制等 摆脱这种模式实际上代表了安全团队的重大转变,安全团队习惯于强迫开发人员遵守他们的流程和工具。
但是Kubernetes是一个大型、复杂的平台;在规模扩大以后,Kubernetes平台自身身的安全问题如何解决?应该采取什么策略来保证应用的安全部署?下面我从四个方面说明如何缓解这些挑战。 功能丰富的Kubernetes平台可能会认为默认该功能具有挑战性,但是弄清楚默认功能是必不可少的。 组织可以使用安全性基准来增强Kubernetes的安全性。 例如,Internet安全中心提供了配置指南,以加强包括Kubernetes在内的系统以抵抗不断发展的网络威胁。 列举出来Kubernetes集群面临的威胁有哪些? 如果您没有人力或时间独自加强Kubernetes安全性。 另外在做安全性方面的考虑时,应该尽可能使用和参考随时可用的工具和技术,而不是闷头造车;比如Kubernetes社区给我门提供了RBAC、pod安全策略、网络策略、服务网格、operators等安全性方案
常见的 Kubernetes 配置错误以及如何避免它们 由于配置错误、工具差距或培训不足导致的安全能力“紧张”,不良的安全态势会影响您响应新出现的威胁的能力。 保护控制平面和 API 访问 一种经常被忽视的 Kubernetes 安全措施是保护控制平面,它通常在托管 Kubernetes 服务中公开。 Kubernetes 姿势中的其他安全措施增强了事件检测和响应能力。 为容器运行时安全性使用准入控制器 并非所有 KSPM 解决方案都提供准入控制,但它对于 Kubernetes 部署中的安全性至关重要。 保护您的东西向流量 虽然 Kubernetes 集群是一个安全边界,但将其视为对主机和网络拓扑的抽象至关重要。
在使用 Kube Bench 的过程中注意到,其指导依据来自于 CIS Benchmark,于是顺藤摸瓜,下载了 CIS Kubernetes Be nchmark 的 PDF 版本,全文有两百多页,阅读量还蛮大的 二级:仅建议在非常强调安全性的系统中使用,可能对系统有副作用。 另外还将具体的检测结果分为计分和不计分两种结果。 以上两个维度可以用来对系统进行现状评估,也有助于读者选择性地采纳加固措施。
在之前的周会上汇报Kubernetes学习结果的时候,被问到一个问题:“一个Service能否提供多种服务,能否代理多组Pod副本?”这里来做一定的研究。 Service基本概念 Kubernetes里的每个Service其实就是微服务架构中的一个“微服务”。 Service定义了一个服务的访问入口地址。 常规做法 Kubernetes做法 部署一个负载均衡器,为这组Pod开启一个对外的服务端口,如8000端口,并将这些Pod的Endpoint列表加入8000端口的转发列表中,客户端就可以通过负载均衡器的对外 相较常规做法,Kubernetes的Service不是共用一个负载均衡器的IP地址,每个Service都被分配了一个全局唯一的虚拟IP地址(Cluster IP),每个服务就变成了具备唯一IP地址的“通信节点 Kubernetes Service支持多个Endpoint,在存在多个Endpoint的情况下,要求每个Endpoint定义一个名字来区分。
目录 Srevice Service 的创建及现象 Service 定义 Endpoint slices 创建 Endpoint、Service Service 创建应用 创建 Endpoint 浅入Kubernetes Kubernetes Service 定义了一种抽象:逻辑上的一组 Pod,一种可以访问它们的策略 —— 通常称为微服务。 Endpoint slices ”端点切片(Endpoint Slices) 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点 (network endpoints)。 “ 在 Kubernetes 中,EndpointSlice 包含对一组网络端点的引用。 指定选择器后控制面会自动为设置了 选择算符 的 Kubernetes 服务创建 Endpoint。 你正在将工作负载迁移到 Kubernetes。 在评估该方法时,你仅在 Kubernetes 中运行一部分后端。
然后,再深入探讨 Kubernetes 安全的“4C”框架,并介绍一些主动解决安全漏洞的策略。 Kubernetes 及其组件 要了解 Kubernetes 的安全性,我们需要深入学习 Kubernetes 在高层次上是如何工作的。 考虑到这种架构,让我们探索一些适用于 Kubernetes 环境的安全最佳实践。 因此,可以在 Kubernetes 安全性的 4C 上下文中考虑安全性:云、集群、容器和代码。 安全的 Kubernetes 基本配置 开始使用 Kubernetes 时,会为业务所处的环境进行基本配置。但是,这些本质上并不安全。