容器云平台的基础安全和管理安全设计

【导读】作为平台级的容器环境,比以往任何的基础架构平台更加的接近业务,同时也包含了更多的层级和组件,因此也带来了更多的风险,容器平台基础组件部分和容器云管理平台部分是容器云平台安全设计的关键。本文列举了容器平台安全的几个典型风险,并分享了容器云平台基础安全设计和管理安全设计的方法经验。

1 容器云平台风险及挑战

容器云平台是通过容器编排引擎及容器运行时等技术提供应用运行平台,从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源,进而提高研发运营的效率,目前市场上主流的容器云平台是基于Google Kubernetes(简称k8s)容器编排引擎和容器引擎建立。本文中介绍内容也是针对此类的容器云平台。

作为平台级的容器环境,比以往任何的基础架构平台更加的接近业务,同时也包含了更多的层级和组件,因此也带来了更多的风险;目前容器安全也是一个信息安全的新兴领域,该领域的技术和产品也在不断完善中,下面我们先从风险的角度列举几个常见的例子,让大家对容器平台安全有个感性认识:

1.1 软件漏洞风险

容器的设计虽然实现了良好的操作系统级隔离,但同时也存在很多安全隐患,比如容器是运行在宿主机上的一种特殊的进程,那么多个容器之间使用的就还是同一个宿主机的操作系统内核,其次在Linux内核中,有很多资源和对象是不能被Namespace化的,最典型的例子是:时间,即如果某个容器修改了时间,那整个宿主机的时间都会随之修改,非计划内的修改系统时间,对于时间敏感的应用可能引起数据错误甚至进程crash,老版本Oracle数据库就存在这样的问题。

Kubernetes作为容器编排引擎,如果在规划和部署架构方面存在缺陷,同样会和传统环境一样容易受到外部攻击者和具有恶意的内部人员的攻击。因此,需要保障大型容器云环境具有正确的安全部署体系结构,并为应用上云提供安全最佳实践。

根据国家信息安全漏洞库的统计,截止2019年1月2日,Docker相关的漏洞共40个,其中包括Apache、RedHat、hyper、boot2docker、Jenkins等厂商产品或开源项目。

2018年,Kubernetes生态系统因发现Kubernetes的第一个主要安全漏洞(Kubernetes特权升级漏洞 CVE-2018-1002105)而动摇。该漏洞使攻击者能够通过k8s api server实现提升k8s普通用户到k8s api-server的最高权限,然后运行代码来安装恶意软件,进而破坏k8s集群。除此之外还有CVE-2019-11245 Kubernetes kubelet v1.13.6 and v1.14.2提权漏洞,实现了在通常情况下以容器Dockerfile中指定的USER运行的容器,有时可以以root身份运行(在容器重启时,或者如果镜像先前被拉到节点)。这种情况的出现违反了容器禁止以root(容器内进程运行用户是root)运行的最佳实践。

1.2 API安全风险

此部分集中关注容器云平台基础组件提供的api服务的安全问题,比如k8s api server,如果在构建容器云平台时扩展或者封装了平台管理api,也需要关注并进行加固。

Docker很多服务默认监听在Unix Socket上,比如unix:///var/run/docker.sock,为了实现集群管理,还提供了一个远程管理接口的REST API,允许通过TCP远程访问服务。开启没有任何加密和访问控制的Docker Remote API服务是非常危险的。尤其是将默认的2375端口暴露到互联网中,一旦被攻击者发现,攻击者无需认证即可访问到容器数据,从而导致敏感信息泄露,也可以恶意删除容器上的数据,或可进一步利用容器自身特性,直接访问主机上的敏感信息,获取服务器root权限,对敏感文件进行修改并最终完全控制服务器。

在容器编排引擎kubernetes通过api server服务提供以下能力:

1.提供了容器平台管理的REST API接口;

2.提供其他模块之间的数据交互和通信的枢纽;

3.资源配额控制的入口;

4.应用部署的接口;

通俗来讲,api server就是整个容器平台的入口,任何用户和程序对集群资源的增删改查操作都可以通过api server实现。因此,为了保证集群的安全,API-server需要提供完备的安全机制。

1.3 镜像安全风险

开发者通常会在公共仓库下载镜像,这些镜像一部分来源于开发镜像相应软件的官方厂商,但还有大量镜像来自第三方组织甚至个人。比如一些自由软件,由于开源和自由获取等特性在大量使用,同时由于没有固定商业组织进行支持,此类软件的镜像多数是社区维护,镜像的质量参差不齐,更有甚者,可能镜像就是不怀好意的黑客制作,如果一旦此类镜像在生产环境使用,势必造成安全隐患。

此外,在整个应用开发生命周期中,开发人员、测试人员和运维人员都有可能根据不同需求下载并运行第三方镜像,所以在容器运行前进行镜像检查非常重要。

1.4 网络安全风险

企业内部容器云平台一般在边界上有很强的安全保障措施,但是在容器云平台内部,基于默认的网络模型,比如flannel,各个容器pod节点是扁平的,在横向网络访问隔离方面缺少必要的安全保障,基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型,优势是成熟,简单,但却缺乏访问控制。

企业内部容器云平台一般在边界上有很强的安全保障措施,但是在容器云平台内部,基于默认的网络模型,比如flannel,各个容器pod节点是扁平的,在横向网络访问隔离方面缺少必要的安全保障,基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型,优势是成熟,简单,但却缺乏访问控制。

企业需要在构建容器云平台时考虑如何增强网络访问控制,进而提升网络安全。

2 容器云平台安全设计容器云平台架构

典型容器云平台,参照上面平台架构设计,包括如下几部分,从下到上包括分别是:

  • 基础设施

  • 容器云平台基础组件部分

  • 容器云管理平台部分

  • 业务应用部分

  • 平台支持系统部分

其中,基础设施部分是容器云平台的基石,提供了容器云平台的运行基础计算、网络、存储资源。此部分和原来传统数据中心运行的情况一致,安全要求也没有明显变化,因此相关安全设计要求参照原来数据中心设计规范进行设计以及实现,不作为容器云安全设计的重点。

容器云平台基础组件部分提供容器云基础功能,主要包括容器运行时实现和编排引擎,其中运行部分包括虚拟化,软件定义网络,软件定义存储,编排引擎主要是kubernetes软件;容器云管理平台部分主要实现了容器平台的核心功能,比如容器调度功能,账户功能(也称租户功能),镜像管理功能,持续集成持续交付部分,此外还包括图形化和命令行管理接口以及方便第三方对接的平台API接口。容器平台基础组件部分和容器云管理平台部分是容器云平台安全设计的关键。

业务应用部分,主要是容器平台上部署的业务应用,有些容器云平台也提供了应用市场功能。根据云平台责任分担模型,此部分安全是业务功能实现方提供,云平台给出一定的安全最佳实践指导。

平台支持系统部分主要是容器平台自建或者对接的第三方系统,比如日志、监控、告警,代码管理,账户管理等。此部分系统对于容器云平台运行至关重要,但是相关系统的安全设计不在本次重点考虑范围内。

容器云平台是一个多模块组成的复杂系统,各个组合模块的安全需要独立设计以及实现,结合上面容器平台的架构,给出容器云平台安全设计架构图,如下:

容器云平台安全架构

2.1 基础安全设计

2.1.1 容器运行时安全

容器运行时通常会给管理员提供多种配置选项。容器运行时配置不当会降低系统的相对安全性。例如,在Linux容器主机上,经允许的系统调用集合通常默认仅限于容器安全运行所必需的调用。如果该列表被扩大,则被入侵的容器会让其它容器和主机操作系统面临更大风险。同样,如果容器在特权模式下运行,则可以访问主机上的所有设备,从而让其本质上成为主机操作系统的一部分,并影响在主机操作系统上运行的所有其它容器。

运行时配置不安全的一个示例是允许容器在主机上挂载敏感目录。容器通常很少会对主机操作系统的文件系统进行更改,而且几乎不应该更改控制主机操作系统基本功能的位置(例如,Linux容器的/boot或/etc、Windows容器的C:Windows)。如果允许遭到入侵的容器更改这些路径,那么,也可以被用来提权并攻击主机本身以及主机上运行的其它容器。

1.安全基线

  • 建设安全基线(参照附件5和6)持续改进

  • 建设安全基线检测自动化工具

  • 建设容器资产清单工具,实时洞察容器运行状况

2.容器运行风格选择

容器运行风格方面,其实有多种选择,采用何种容器运行风格也是安全考虑的问题之一:

常见运行风格:

瘦容器(Thin Container):单进程应用的封装,在镜像中打包应用。这非常适于微服务架构应用的服务交付。

胖容器(Fat Container):多进程应用的封装,在镜像中打包应用。容器引擎对进程管理的特殊性,我们会利用init.d/systemd或者supervisor等来启动管理进程。但是容器应该尽可能是单一目的,容器中的进程应该是紧耦合的,并有一致的生命周期。比如可以将“nginx”和“php-fpm”打包在一个容器镜像中。

VM容器(VM Container):是利用容器模拟轻量级虚拟机:镜像本身不包含应用,需要利用在容器启动后动态安装和配置应用。这是不建议的方案,会造成容器中应用配置管理和更新的复杂性。如业务应用暂时无法改造,需要制定过渡方案。一般而言,不建议选择VM容器风格。

2.1.2 Kubernetes运行时安全

目前主流的容器云管理平台一般基于kubernetes构建,kubernetes平台采用分布式架构方式构建,根据平台功能由多个组件组成,如下图。典型的组件包括api server,etcd,sheduler,controller manager,kubelet,kube-proxy,cAdvisor,Plugin networks(比如flannel)等。以上组件是容器云平台的控制(管理)平面,是容器云平台的大脑,全面洞察集群上的每一个容器和pod,并且调度新的pod,读取和存储集群中的所有私密信息,因此在通讯和数据存储和传输方面均需要严格安全包括,主要措施包括:

组件安全基线

Kubernetes安全运行需要满足必要的配置基线,关于基线建设包括:

  • 建设安全基线(参照NIST规范,CIS benchmark)持续改进

  • 建设安全基线检测自动化工具

组件之间通信加密

为了实现组件之间的安全,设计要求组件之间应该启用TLS,支持TLS以防止流量嗅探、验证服务器身份以及(对于相互TLS而言)验证客户端身份。

需要开启的TLS通讯包括:

1.API Server和etcd之间

2.API Server和Controller Manager之间

3.API Server和Scheduler之间

4.API Server和Kubelet之间

5.平台管理用户和API Server之间

6.Kubelet和容器之间

7.业务用户和业务pod之间(可选)

参考下图:

2.1.3 网络安全

网络隔离

K8s的网络策略应用于通过常用标签标识的pod组。然后,使用标签来模拟传统的分段网络,这些网络通常用于在多层应用程序中隔离层:例如,可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量,甚至控制来自外部源的流量。

简单路由网络或常用的flannel网络程序本身不能应用网络策略。

目前Kubernetes只有几个支持网络策略的网络组件:Romana,Calico和Canal;其中Weave在不久的将来指示支持,Red Hat的OpenShift包括了网络策略功能。因此如何容器云平台基于OpenShift构建会获得OOTB的网络策略功能。

从网络模型的流行度来看,flannel的网络方案最流行,市场占有率较大,基于calico+network policy的方案逐步成熟中,可以持续跟进,在容器云构建中可以在测试环境中进行验证。

在一些落地的方案中,容器云平台建设过程中采用flannel的方案,但是通过为不同安全级别的应用(租户)建设不同的集群而实现应用(租户)网络隔离。

南北向流量的安全

对于南北向的流量,应该引入传统的网络流量分析控制设备,例如IPS/IDS/审计/NGFW/WAF等。

东西向流量的安全

东西向流量的安全也是非常关键的,目前可以采用的技术和产品比较少,但这个方面却是非常关键的安全控制点,在没有合适的产品可以替代的情况下,应该尽量:

1.采用Mini Knernel的容器化操作系统;

2.非特权用户运行容器;

3.采用强制访问控制技术;

4.监控宿主机文件系统的变更;

5.保持系统和组件的安全补丁为最新。

2.2 管理安全设计

2.2.1 管理平台安全建设

建立专属CA中心,定期替换密钥

在组件TLS加密通讯的关键因素是证书的安全,默认情况下,kubernetes集群搭建使用的私有CA,并且生成临时的证书进行TLS加密通讯,但是为了保障TLS的有效性,保障CA更证书的私密以及以及降低组件证书的泄漏风险,因此建议集群的专属CA中心,并且设置组件证书的有效期,在组件证书快到期的时候进行替换。

检查根证书到期时间的命令:

openssl x509 -noout -enddate -in /etc/kubernetes/ssl/kubelet-client.crt

2.2.2 用户权限安全管理

容器云平台的4A(即认证Authentication、账号Account、授权Authorization、审计Audit)管理功能设计。

构建统一账户管理平台(UIMS)

容器平台是一个多组件组成的平台系统,每个组件自成系统,比如镜像管理,CI/CD平台,日志系统,监控系统等,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了平台的协调工作,因此构建统一的标准化账户管理体系将是必不可少的。

统一账户系统平台可带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件。

基于『统一身份治理』的概念,可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类,个人实体从属于组织实体,也可以不从属任何组织实体,且个人实体可同时从属于多个组织实体;基础权限模块将各业务系统的资源权限进行统一管理和授权;基础信息模块用于描述组织实体和个人实体的基本信息,如组织实体名称、地址、法人,个人实体姓名、电话号码、性别等基础信息。此外统一账户系统提供统一的API与其他系统对接。

对于账户的口令需要建立严格的管理机制,因为一个好的口令策略是防止未授权访问的一个最重要的安全屏障,减少弱口令风险是提升系统安全性的投入产出比最高的方式。

建设过程中需要对容器云平台,组织实体,个人实体等账户的口令进行分类,建立平台超级管理员口令,组织管理员口令,个人实体口令管理办法,典型的云平台超级管理员口令的安全性要求最高,组织管理员次之,个人实体口令要求相对低一些,因此口令的管理措施也不同,比如云平台超级管理员需要建设基于硬件的一次性密码或者双要素密码认证机制,组织管理员密码需要建立一次性密码或者双要素密码认证机制,个人实体密码需要满足一定密码复杂度要求。

典型口令策略,举例:

  • 密码至少由8个字符组成,应该混合数字、大写字母、小写字母,以及特殊字符等;

  • 所有系统管理员级别的密码必需每三个月更换一次,并依照规定进行存档备份。普通个人密码六个月更换一次。

  • 用户所使用的任何具备系统超级用户权限账号密码必需和这个用户其他账号的密码均不相同。

  • 重要的系统密码比如云平台超级管理员,组织管理员采用一次性密码或者双要素密码认证。

UIMS系统支持完备口令使用,变更,修改,注销等生命周期管理能力。

另外需要通过管理规定,严格要求密码使用时注意保护,比如不要把自己密码共享给他人,不要在email中写密码,不要给你上司密码等。

技术实现方案方面,可以通过Microsoft AD,Oracle Identity Management,OpenLdap等软件实现。在一个成熟企业内部基本上已经具备类似系统并且稳定运行。因此此对于容器云平台建设来说主要是统一对接,统一纳管,统一管理的问题。如果企业内部没有需要单独设立子项目建设UIMS系统。

构建统一身份认证平台SSO

容器云平台实现统一身份认证和传统应用原理一样,区别在于kubenetes支持的身份严重方式有不同要求,常见的统一身份认证方式归纳为以下两类:

1.传统的Cookie+Session解决方案,有状态会话模式;

2.基于令牌/票据的解决方案,无状态交互模式。

具体有:

  • 分布式Session

  • OAuth2.0

  • JWT

  • CAS

上述方案各有利弊:

分布式Session是老牌的成熟解决方案,但因其状态化通信的特性与服务提倡的API导向无状态通信相互违背,且共享式存储存在安全隐患,因此微服务一般不太采用。

OAuth2.0是业内成熟的授权登录解决方案,然而OA2.0提供了4种授权模式,能够适应多种场景,作为基于令牌的安全系统,可以广泛用于需要统一身份认证和授权的场景。

JWT(JSON Web Token)是一种简洁的自包含的JSON声明规范,因其分散存储的特点而归属于客户端授权模式,广泛用于短期授权和单点登录。由于JWT信息是经过签名的,可以确保发送方的真实性,确保信息未经篡改和伪造。但由于其自包含的客户端验签特性,令牌一经签发,即无法撤销,因此单纯采用JWT作为统一身份认证和授权方案无法满足帐号统一登出和销毁、帐号封禁和解除这几种类型的需求。

CAS是时下最成熟的开源单点登录方案,包含CAS Server和CAS Client两部分。CAS Server是一个war包需要独立部署,负责用户认证;CAS Client负责处理对客户端受保护资源的访问请求,需要认证时,重定向到CAS Server。值得注意的是,CAS是一个认证框架,其本身定义了一套灵活完整的认证流程,但其兼容主流的认证和授权协议如OAuth2、SAML、OpenID等,因此一般采用 CAS+OAuth2的方案实现SSO和授权登录。

Kubernetes有三种主要的身份验证方法,用于和API进行交互。官网列出了更多的认证方法,但以下三种是用户认证常见的方法。

  • 静态密码

  • X.509客户端证书

  • OpenID Connect(OIDC)

其中,OpenID Connect基于OAuth 2.0协议。

结合kubernetes的支持能力以及常见的方案,容器云平台SSO参照实现方案可以采纳Dex或者Keycloak。

构建最小权限授权管理机制

所有对容器云的访问均通过kubernetes api server实现,其中访问控制的规则也是在api server进行设置,在最新的Kubernetes中ABAC(基于属性的访问控制)已被RBAC取代,ABAC不建议api server上启用,需要使用RBAC,启用方式是:

–authorization-mode=RBAC

除此之外还有以下模式:

–authorization_mode=AlwaysDeny

–authorization_mode=AlwaysAllow

–authorization_mode=ABAC

–authorization_mode=Webhook

–authorization_mode=Node

容器云平台RBAC授权管理机制涉及的概念包括:

1.访问对象定义:

K8s对集群内部的对象以及对象上有的操作进行了规范,比如对象包括(不含CRD对象):

  • Pods

  • ConfigMaps

  • Deployments

  • Nodes

  • Secrets

  • Namespaces

2.对象操作定义:

资源对象的可能存在的操作有:

  • create

  • get

  • delete

  • list

  • update

  • edit

  • watch

  • exec

3.角色/集群角色定义:

角色是针对以上资源上的一组操作的集合

k8s对于role进行了区分,分为角色(Role)和集群角色(ClusterRole),其中在角色Role中,定义的规则只适用于单个命名空间,也就是和namespace关联的,而ClusterRole是集群范围内的,因此定义的规则不受命名空间的约束。

4.用户/服务账户/组定义:

在Kubernetes集群中有存在两类用户:

service accounts:由Kubernetes进行管理的特殊用户;

user(普通用户):普通用户是由外部应用进行管理的用户。

Group:组,这是用来关联多个账户的,集群中有一些默认创建的组,比如cluster-admin

对于普通用户,Kubernetes管理员只负责为其分配私钥。普通用户可能来自于Keystone或ldap中,或者甚至是存储在文件中的用户名和密码列表。在Kubernetes中,没有表达普通用户的对象,因此,也就不能通过API将普通用户添加到集群中。

而Service Account是由Kubernetes API管理的用户,它们被绑定到特定的命名空间中,并由API服务器自动创建或通过API调用手动创建。Service Account与存储在Secrets的一组证书相关联,这些凭据被挂载到pod中,以允许集群中进程与Kubernetes API进行通信。

API请求要么来自于普通用户或Service Account,或来自于匿名请求。这就意味着集群内外部的所有进程(从来自于用户使用kubectl输入的请求,或来自于Nodes中kubelet的请求,或来自控制板的成员的请求)都需要进行认证才能与API server进行交互。

5.角色绑定/集群角色绑定定义:

RoleBinding和ClusterRoleBinding:角色绑定和集群角色绑定,简单来说就是把声明的Subject和我们的Role进行绑定的过程(给某个用户绑定上操作的权限),二者的区别也是作用范围的区别:RoleBinding只会影响到当前namespace下面的资源操作权限,而ClusterRoleBinding会影响到所有的namespace。

在有以上定义的基础上,容器云平台的基于rbac管理模型下的权限管理方式:某一用户(service account或者User)通过角色绑定定义了该用户具有哪些角色,该角色详细记录具有对哪些对象的那些操作,即改用户具有了对哪些对象进行哪些操作的能力。

在容器云平台授权管理部分还是和传统应用一样,一定授权秉承最小权限原则,对于用户的权限进行最小化设置,并且对于用户的权限进行周期性review、及时清理比不必要的用户和权限定义。

小提示:关于如何实为集群服务设置RBAC策略的最佳实践,以及归纳典型设置可以使用audit2rbac,从审计日志提取细粒度的RBAC策略。

开启审计功能(非强制)

审计功能主要包括两部分内容,一个是k8s api调用审计,一个是管理平台页面操作审计,审计记录均以日志的形式上收到日志平台统一管理,其中api审计日志通过开启k8s audit功能实现,管理平台的审计日志通过管理平台的实现方自定义实现。

其中api server(kube-apiserver.yaml)开启audit日志的方式是:

–feature-gates=AdvancedAuditing=true

–audit-policy-file=/etc/kubernetes/pki/audit-policy.yaml

–audit-log-format=json

–audit-log-path=/var/log/kubernetes/kubernetes-audit

–audit-log-maxage=30

–audit-log-maxbackup=3

–audit-log-maxsize=100 

其中audit策略在文件audit-policy.yaml定义,形如:审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时,将按顺序与规则列表进行比较。第一个匹配规则设置事件的[审计级别][auditing-level]。已知的审计级别有:

None-符合这条规则的日志将不会记录。

Metadata-记录请求的metadata(请求的用户、timestamp、resource、verb等等),但是不记录请求或者响应的消息体。

Request-记录事件的metadata和请求的消息体,但是不记录响应的消息体。这不适用于非资源类型的请求。

RequestResponse-记录事件的metadata,请求和响应的消息体。这不适用于非资源类型的请求。

目前对于容器云上的API Server审计日志的支持,推荐的日志采集的方式是通过日志采集平台将数据采集到日志中心,通常日志中心是基于大数据理念建设的海量数据存储平台,审计日志的查询配合特定索引进行根据关键字的查询,审计日志保存内容以及保存时间需要遵从相关行业规定,通常日志内容需包含时间、用户、操作模块、操作行为等信息,同时建议在线日志保存一个月以上,此外定期对审计日志进行备份存档(三级系统归档日志至少保存3个月)。

2.2.3 租户资源访问安全

根据上面容器平台的架构图,我们可以发现容器底层资源是以池化的方式供上层应用进行消费使用的,通过云平台支持多租户模型,提供了多个业务主体应用并行运行的能力,其实这也是云平台的关键特征之一。

共享的现状为业务的运行提供弹性伸缩的能力,可以实现对多个业务压力削峰填谷的效果,最大限度的提升了资源的利用率。

但是共享也带了来一定的隐患,比如恶意访问,资源恶意抢占等,因此容器平台需要实现容器资源隔离的能力,目前kubernetes提供的能力包括:

1.资源的访问隔离通过namespace机制对容器云平台进行多租户资源隔离,租户内基于RBAC模式的授权模式进行资源的访问控制。

2.对于资源请求量方面,admission control是一种多维度可扩展的资源管理机制,每个维度通过一个admission control插件实现。与Kubernetes用户认证与授权模块一样,对admission control的调用也是由api server来完成的。

目前支持的admission control插件,分别是

NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultSeconds,DefaultStorageClass,StorageObjectInUseProtection,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass,ResourceQuota

以上插件按需激活使用,比如:

… …

–enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,Resourc

eQuota

… …

3.Node selector机制

此设置是资源隔离的一种方式,但此方式并不是平台构建层面需要考虑的措施,需要以规范或者最佳实践的方式通知应用部署人员,按照规范部署实施。

此功能原理是让kubernetes集群调度器根据node selector的设置为pod资源选择某个节点(如果未设置,默认是调度考虑的是资源足够,并且load尽量平均)。

4.网络隔离

网络资源在集群层面也是共享的,相关的隔离措施见前面部分。

单集群和多集群

在某些行业中比如金融业,监管部门要求一个业务的前端,后端需要部署在不同的网络区域中,因此容器云平台在建设过程中,需要考虑集群跨网断或者多集群部署的问题,此外随着一个集群的业务不断增加,也需要在容量上做对集群拆分。因此在构建容器云平台时建议规划好集群的部署形式。

建议:

  • 不同环境部署多个集群,比如UAT测试,SIT测试,性能测试。

  • 不同网络区域部署多个集群,比如DMZ区域,业务后台区域。

  • 不同地域部署多个集群,比如生产区域和灾备区域

  • 不同业务安全级别的应用部署在不同集群。

  • 单个集群不能太小,同时也不能太多,建议不超过128台物理主机(48c/256G)。

2.2.4 组件安全

Kubernetes平台本身是一个可扩展的平台,通过CNI支持不同的网络组件,通过CSI支持不同的存储组件,此外通过CRD能力支持不同的客户化资源定义,常见的功能扩展比如CI/CD,日志,监控,告警。以上组件通过CRD的方式部署在kubernetes集群内,扩展了容器云平台的能力,此外在应用层面,微服务运行组件也以组件的方式部署在容器云平台上。比如Spring Cloud,istio等微服务框架,因此以上组件的安全需要进行相关的设计,鉴于容器云平台的建设规模,各个容器云平台的组件也不相同,本文中以最基本的CI/CD组件为例介绍组件的安全设计要求:

1.数据与环境隔离:不同项目、不同团队的数据要保证隔离,一个项目的多套环境,多套介质同样要保证隔离,比如介质库,首先各项目的介质库要隔离,一个项目的开发库、测试库、投产库同样要隔离,测试通过的介质,则通过可控的同步手段发到投产库。另外比如部署引擎,什么引擎可针对什么环境进行部署操作,也是严格控制的,防止环境操作越权。

2.UI与API的权限控制:对界面的菜单、按钮进行权限控制,对后台api的访问权限进行权限控制,其中账户部分需要对接统一的LDAP系统。

3.可审计:对于什么人在什么时候在平台上做了什么,在动作前后资源产生了这样的变更,比如部署的操作,什么人审批还是可自动执行,部署完成后由谁确认(亦或是通过自动化测试确认),这些关键事项,需要结合不同团队的实际情况进行不同的个性化配置。

4.平滑升级:组件的升级应该不影响容器云平台的影响。

添加微信免费咨询高性价比云主机信息
微信号:landuiYY

未经允许不得转载:云技术 » 容器云平台的基础安全和管理安全设计

赞 (0)