平安云 - 云以致用智造未来

Kubernetes安全配置建议

1.  容器使用可信任的基础镜像 确保容器镜像是从头开始编写的，或者是基于通过安全仓库下载的另一个已建立且可信的基础镜像。官方仓库是由Docker社区或供应商优化的Docker镜像。可能还存在其他不安全的公共仓库。在从Docker和第三方获取容器镜像时需谨慎使用，来源不可信的镜像可能包含未知的漏洞和恶意攻击行为，对应用和平台都可能造成损害。 相关参考 (1)    https://titanous.com/posts/docker-insecurity (2)    https://registy.hub.docker.com/   2.  定期扫描镜像漏洞并且构建包含安全补丁的镜像 应该定期扫描镜像以查找漏洞，对于有漏洞的镜像安装最新的安全补丁。安全补丁可以解决软件的安全问题，可以使用镜像漏洞扫描工具来查找镜像中的漏洞，然后检测可用的补丁以减轻这些漏洞，重新生成了安全镜像后可以通过kubernetes的滚动升级功能便捷的升级现有应用的镜像。 相关参考 (1)    https://docs.docker.com/docker-cloud/buids/image-scan (2)    https://blog.docker.com/2016/05/docker-security-scanning/   3.  确保仅在需要时使用cluster-admin role Kubernetes提供了一组使用RBAC的默认角色，其中一些角色（如cluster-admin）提供了广泛的权限，只应在绝对必要的地方应用。例如，cluster-admin的角色允许超级用户访问，以对任何资源执行任何操作，在ClusterRoleBinding中使用时，它可以完全控制集群和所有名称空间中的每个资源，在RoleBinding中使用时，它可以完全控制rolebinding命名空间中的每个资源，包括命名空间本身。因此，建议cluster-admin角色仅在需要的地方和时间使用。 相关参考 https://kubernetes.io/docs/admin/authorization/rbac/#user-facing-roles   4.  使用命名空间(namespace)在资源之间创建管理边界 使用命名空间隔离您的Kubernetes对象。限制用户权限的范围可以减少错误或恶意活动的影响。Kubernetes的命名空间(namespace)允许您将创建的资源划分为逻辑命名的组，在一个命名空间中创建的资源可以从其他名称空间隐藏。默认情况下，用户在Kubernetes集群中创建的每个资源都在default这个命名空间中运行。您可以创建其他命名空间并将资源和用户附加到这些命名空间，来实现不用用户组只能操作自己命名空间下的资源，以避免越权操作影响到其他用户组的资源。 相关参考 (1)    https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ (2)    https://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html   5.  合理设置POD的资源请求resource 给POD设置适当的resource资源配置能够做到提示集群和应用的稳定性、提高节点资源使用率，resource包括request和limit两个字段。 <ul> <li>request</li> </ul> 容器使用的最小资源需求，作为容器调度时资源分配的判断依赖。只有当节点上可分配资源量>=容器资源请求数时才允许将容器调度到该节点，但Request参数不限制容器的最大可使用资源。 <ul> <li>limit</li> </ul> 容器能使用的最大资源需求，设置为0表示使用资源无上限。 Request能够保证Pod有足够的资源来保证应用运行的最小需求保障，而Limit则是防止某个Pod无限制地使用资源，导致占用过多的节点资源，影响其他Pod和节点的稳定性。 Pod的每个Container都可以指定以下一项或多项： spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory 在应用的yaml配置文件的resource字段，可以设置memory和limit的值，虽然只能在单个Container上指定请求和限制，但是讨论Pod资源请求和限制很方便。特定资源类型的 Pod资源请求/限制是Pod中每个Container的该类型的资源请求/限制的总和。如下示例，表示给test-limit应用的POD设置了最小256M、0.5个CPU，最大512M、1个CPU的资源限制。 spec:   containers:     - name: test-limit       image: demo:1.0       resources:         requests:           memory: "256Mi"           cpu: "500m"         limits:           memory: "512Mi"           cpu: "1000m" 创建Pod时，Kubernetes调度程序会选择要运行Pod的节点。每个节点都有每种资源类型的最大容量：它可以为Pod提供的CPU和内存量。调度程序确保对于每种资源类型，计划容器的资源请求总和小于节点的容量。请注意，虽然节点上的实际内存或CPU资源使用率非常低，但如果容量检查失败，调度程序仍拒绝在节点上放置Pod。 相关参考 https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/   6.  合理使用资源配额(ResourceQuota) Resource Quotas（资源配额）是kubernetes对namespace进行资源配额，限制资源使用的一种策略。Kubernetes通过命名空间(namespace)实现多租户资源隔离，基于命名空间配置好该命名空间的资源配额，能避免单个命名空间使用集群过多的资源导致其他租户资源不足。 如下操作是创建了一个名为myspace的命名空间，并在该命名空间下创建了ResourceQuota，限制了myspace命名空间下所有POD个数不超过4个，最小请求的cpu使用量之和不超过1个CPU，最大请求的cpu使用量之和不超过2个CPU，最小请求的memory使用量之和不超过1G, 最大请求的memory使用量之和不超过2G。 kubectl create namespace myspace cat <<EOF > 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 EOF kubectl create -f ./compute-resources.yaml --namespace=myspace 相关参考 https://kubernetes.io/docs/concepts/policy/resource-quotas/

以上内容是否解决了您的问题？是否