kubernetes

Kubernetes 部署安全最佳实践

编者按:本文作者是来自 Aqua Security 的 Amir Jerbi 和 Michael Cherny,他们以大量的案例和经验为基础,总结并描述了 Kubernetes 部署中的最佳安全实践。

Kubernetes 提供了很多能够提高应用安全的方法。要进行这些配置,就要掌握 Kubernetes 的相关知识,同时也要清楚的了解安全需求。这里我们关注的安全内容集中在容器的生命周期上:构建、传输以及运行,并且针对 Kubernetes 进行了特别的裁剪。我们自己的 SaaS 就是运行在 Google Cloud Platform 上的 Kubernetes 中,已经采用了这些最佳实践。

下面是我们对于安全部署 Kubernetes 应用的一些建议。

确保镜像无漏洞

运行带有漏洞的容器会让你的环境身处险境。只要运行中的系统的所有组件都不存在已知漏洞,就能够避免很多被攻击的机会。

Minikube:轻松运行本地 Kuberntes 集群

Kubernetes 已经是目前最佳的应用容器化工具之一。在投入实际使用之后的一年来,Kubernetes(社区)需要一个本地开发平台。

在过去的几个月中,Kubernetes 社区中的很多成员在为 Github 的 Minikube 仓库 奋战。我们要建立一个可以一键运行的版本,这个版本要易用和准确兼顾,并且能够兼容 Mac、 Linux 以及 windows 的工作站和笔记本电脑。

感谢社区成员的贡献,我们自豪的宣告 Minikube 的诞生,并与 Kubernetes 1.3 一起发布,新的命令能够更好的跟本地集群通信,并且加入了试验性的对 xhyve(OS X)以及 KVM(Linux)的支持。

使用 Minikube

Minitube 是一个独立的 Go 应用,所以只要下载运行就可以了:

Kubernetes 1.3 的性能和弹性 —— 2000 节点,60,0000 Pod 的集群

我们自豪的宣布 Kubernetes 1.3 的发布,现在能够在支持 2000 节点规模的集群上提供更好的端到端 Pod 启动时间。API 调用的延迟符合我们的一秒钟的 服务水平目标( SLO ),并且多数情况下是远远优于这一目标的。如果不考虑 SLO 限制的话,还可能运行超过 2000 节点的集群。

Kubernetes 中使用 Gluster FS

以 RC 形式运行在 Kubernetes 集群中的 Pod,会因为 Scale 等需要在不同的 Node 之间发生迁移,因此需要有独立于 Node 文件系统的共享存储服务,同时这一存储服务也应该符合集群的运行需要,简单的 NFS 不管是效率上还是可靠性上,都是不具备这一能力的。这里以 Gluster FS 作为存储引擎,为容器集群提供云存储服务。

K8S 的存储卷使用稍有点古怪,Gluster FS 的使用,需要首先定义一个 Endpoint + Service 形式的代理,来定义 Gluster FS 集群,然后就可以通过持久卷或者用 Pod 直接加载了。

定义 Service

首先用一个 YML 文件来定义 Endpoint 和 Service:

Kubernetes 中的 Persistent Volumes

经过一番实验,证明,这东西除了抽象,没啥鸟用,直接挂 Volume 应该是目前最佳选择。

持久卷 PersistentVolumes

本文描述了 Kubernetes 中的 PersistentVolumes。要求读者有对卷 (volumes) 所有了解。

简介

存储管理跟计算管理是两个不同的问题。PersistentVolume 子系统,对存储的供应和使用做了抽象,以 API 形式提供给管理员和用户使用。要完成这一任务,我们引入了两个新的 API 资源:PersistentVolume(持久卷)PersistentVolumeClaim(持久卷申请)

PersistentVolume(PV)是集群之中的一块网络存储。跟 Node 一样,也是集群的资源。PV 跟 Volume (卷) 类似,不过会有独立于 Pod 的生命周期。这一 API 对象包含了存储的实现细节,例如 NFS、iSCSI 或者其他的云提供商的存储系统。

Kubernetes 服务定义示例

Tags: 
---
kind: List
apiVersion: v1
items:
- kind: ReplicationController
  apiVersion: v1
  metadata:
    name: rc-nginx-meta
    labels:
      name: rc-nginx
  spec:
    replicas: 1
    # 必须跟 template 里面的 labels 匹配
    selector:
      name: pod-nginx
    template:
      metadata:
        labels:
          name: pod-nginx
      spec:
        containers:
        - name: nginx-docker-images
          image: nginx:1.10
          # 开放端口数组
          ports:
          - containerPort: 80
            protocol: TCP
          # 环境变量数组
          env:
          - name: NGINX_PORT

kubectl config 文件示例

Tags: 
apiVersion: v1
kind: Config
# Clusters 一节用于存储对多个 Master 的定义,大致包含证书,服务器地址等信息
clusters:
- cluster:
    certificate-authority: certs/pd/ca.crt
    server: https://10.211.55.87:6443
  name: pd-secure
# Users 一节用于存储用户凭据,可对应 Token, Basic 等验证方法
users:
- name: fake-user
  user:
    password: password
    username: admin  
# Contexts 这里会用上面的集群和用户信息,来形成完整的连接信息
contexts:
- context:
    cluster: pd-secure
    namespace: kube-system
    user: fake-user
  name: pd-local
# 当前生效的 Context,可以利用 kubectl config use-context 来切换
current-context: pd-local
preferences: {}

在 Kubernetes 中使用部署(Deployment)对象

Kubernetes 简化了应用的部署管理,大多数操作都可以用一个 API 或者命令行搞定,例如应用生成、金丝雀测试以及升级。我们为什么还需要部署对象?

部署对象把部署和滚动更新进行了自动化。跟 kubectlrolling-update 相比,部署 API 更加清晰快速,在服务端实现,有更多的功能(例如即使滚动更新已经完成,你还是可以回滚到之前的版本)。

页面