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