Kubernetes Application
Kubernetes Busybox
Kubernetes Gitlab
Kubernetes Harbor
Kubernetes Ingress Nginx
Kubernetes Kerberos
Kubernetes NextCloud
Kubernetes Nginx
Kubernetes Openldap
Kubernetes Tomcat
Kubernetes Upload Service
Kubernetes Webmin
Kubernetes Authorization Management
API Service 认证管理 Authentication
API Server 授权管理 Authorization
ABAC 授权模式详解
Webhook 授权模式详解
RBAC 授权模式详解
Admission Control 准入控制
Secret 私密凭据
Kubernetes Authorization Management
Kubernetes 通过一系列机制来实现集群的安全控制，其中包括 API Server 的认证授权、准入控制机制及保护敏感信息的 Secret 机制等。集群的安全性必须考虑如下几个目标。
（1）保证容器与其所在的宿主机的隔离。
（2）限制容器给基础设施及其他容器带来消极影响的能力。
（3）最小权限原则——合理限制所有组件的权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它所能达到的权限范围。
（4）明确组件间边界的划分。
（5）划分普通用户的管理员的角色。
（6）在必要时允许将管理员权限赋给普通用户。
（7）允许拥有 “Secret” 数据（Keys、Certs、Passwords）的应用在集群中运行。
下面分别从 Authentication、Authorization、Admission Contril、Secret 和 Service Account 等方面来说明集群的安全机制。
API Service 认证管理 Authentication
我们知道，Kubernetes 集群中所有资源的访问和变更都是通过 Kubernetes API Server 的 REST API 来实现的，所以集群安全的关键点就在于如何识别并认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）这两个关键问题。
Kubernetes 集群提供了 3 种级别的客户端身份认证方式。
最严格的 HTTPS 证书认证：基于 CA（Certificate Authority）根证书签名的双向数字证书认证方式。
HTTP Token 认证：通过一个 Token 来识别合法用户。
HTTP Base 认证：通过用户名和密码的方式认证。
首先，说一说 HTTPS 证书认证的原理。
这里需要有一个 CA 证书，CA 是 PKI 系统中通信双方都信任的试题，被称为可信第三方（Trusted Third Party，TTP）。CA 作为可信第三方的重要条件之一就是 CA 的行为具有非否认性。作为第三方而不是简单的上级，就必须能让信任着有追究自己责任的能力。CA 通过证书证实他人的公钥信息，证书上有 CA 的签名。用户如果因为信任证书而有了损失，则证书可以作为有效的证据用于追究 CA 的法律责任。正式因为 CA 承担责任的承诺，所以 CA 也被称为可信第三方。在很多情况下，CA 与用户是相互独立的实体，CA 作为服务提供方，有可能因为服务质量问题（例如，发布的公钥数据有错误）而给用户带来损。在证书中绑定了公钥数据和响应私钥拥有者的身份信息，并带有 CA 的数字签名；证书中也包含了 CA 的名称，以便于依赖方找到 CA 的公钥，验证证书的数字签名。
CA 认证设计诸多概念，比如根证书、自签名证书、秘钥、私钥、加密算法及 HTTPS 等，大致讲述 SSL 协议的流程，有助于对 CA 证书和 Kubernetes CA 认证的配置过程的理解。
CA 认证大概包括下面几个步骤：如下图：
（1）HTTPS 通信双方的服务器端向 CA 机构申请证书，CA 机构是可信的第三方机构，它可以是一个公认的权威的企业，也可以是企业自身。企业内部系统一般都用企业自身的认证系统。CA 机构下发根证书、服务端证书及私钥给申请者。
（2）HTTPS 通信双方的客户端向 CA 机构申请证书，CA 机构下发根证书、客户端证书及私钥给申请者。
（3）客户端向服务器端发起请求，服务端下发服务端证书给客户端。客户端接收到证书后，通过索要解密生疏，并利用服务器端证书中的公钥证书信息比较证书里的消息，例如域名和公钥与服务器刚刚发送的相关消息是否一致，如果一直，则客户端认可这个服务器的合法身份。
（4）客户端发送客户端证书给服务器端，服务端接收到证书后，通过私钥解密生疏，获得客户端证书公钥，并用该公钥认证证书信息，确认客户端是否合法。
（5）客户端通过随机密钥加密信息，并发送加密后的信息给服务端。服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥，客户端通过协商好的加密方案，加密该随机秘钥，并发送该秘钥到服务器端。服务器端接收到这个秘钥后，双方通信的所有内容都通过该随机秘钥加密。
如上述是双向认证 SSL 协议的具体通信过程，这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户端拥有 CA 证书，对上面的步骤，只需要将服务器端认证客户端证书的过程去掉，以及在协商对称密码和对称通话秘钥时，服务器发送给客户的是没有加过密的（也并不影响 SSL 过程的安全性）密码方案。
其次，来看看 HTTP Token 的认证原理。
HTTP Token 的认证使用一个很长的特殊编码方式的并且难以被模仿的字符串 —— Token 来表明客户身份的一种方式。在通常情况下，Token 是一个很复杂的字符串，比如我们用私钥前面一个字符串后的数据就可以当做一个 Token。此外，每个 Token 对应一个用户名，存储在 API Service 能访问的一个文件中。当客户端发起 API 调用时，需要在 HTTP Header 里面放入 Token，这样一来，API Server 就能识别合法用户和非法用户了。
最后来看看 HTTP Base 认证。
HTTP 是无状态的，浏览器和 Web 服务器之间可以通过 Cookie 来进行身份识别。桌面应用程序（比如新浪桌面客户端、SkyDrive 客户端、命令行程序）一般不会使用 Cookie，那么它们与 Web 服务器之间是如何身份识别的呢？这就用到了 HTTP Base 认证，这种认证方式是把 “用户名+冒号+密码” 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Header Authorization 域里发送给客户端，服务端收到后进行解码，获取用户名及密码，然后进行用户身份的鉴权过程。
API Server 授权管理 Authorization
当客户端发起 API Server 调用时，APi Server 内部要先进行用户认证，任何执行用户授权流程，即通过 “授权策略” 来决定一个 API 调用是否合法。对合法用户进行授权（Authorization）并且随后在用户访问时进行鉴权，是权限与安全系统的重要一环。简单来说，授权就是授予不同的用户不同的访问权限，API Server 目前支持一下集中策略（通过 API Server 的启动参数 “--authorization-mode” 设置）。
AlawysDent：表示拒绝所有的请求，一般用于测试。
AlwaysAllow：允许接受所有请求，如果集群不需要授权流程，则可以采用该策略，这也是 Kubernetes 的默认设置。
ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配的控制。
Webhook：通过调用外部 REST 服务对用户进行授权。
RBAC：Role-Based Access Control，基于角色的访问控制。
API Server 在接收到请求后，会读取该请求中的数据，生成一个访问策略对象，如果该请求中不带某些属性（如 Namespace），则这些属性的值将根据属性类型的不同，设置不同的默认值（例如为字符串类型的属性设置一个空字符串：为布尔类型的属性设置 false；为数值类型的属性设置 0）。然后将这个访问策略对象和授权策略文件中的所有访问策略对象逐条匹配，如果至少有一个策略对象被匹配，则该请求将被鉴权通过，否则终止 API 调用流程，并返回客户端的错误调用码。
ABAC 授权模式详解
链接
Webhook 授权模式详解
链接
RBAC 授权模式详解
链接
首先在国内从事运维或者创业型互联网公司以及程序员，基础就是有一个服务器作为运行条件，大厂服务器自不必说，今天主要就是推荐几家国内数一数二的大中小企业服务器供应商，首先第一家就是3A网络科技，近20年的技术积累，拥有自建香港机房，同时作为阿里云，百度云合作伙伴，对于这些大厂拥有很高的私企折扣，200G带宽，BGP接入，直接互联骨干网。8年IDC运维驻守机房
为您的网站保驾护航，8年IDC运维驻守机房，为您的网站保驾护航。
Admission Control 准入控制
突破了之前所说的认证和鉴权两道关口之后，客户端的调用请求就能够得到 API Server 的真正相应了吗？答案是：不能！这个请求还需要通过 Admission Control 所控制的一个 “准入控制链” 的层层考验，官方标准的 “关卡” 有近十个之多，而且能自定义扩展！
Admission Control 配置有一个 “准入控制器” 的插件列表，发送给 API Server 的任何请求都需要通过列表中每个准入控制器的检查，检查不通过，则 API Server 拒绝此调用请求。此外，准入控制器插件还能够修改请求参数以完成一些自动化的任务，比如 ServiceAccount 这个控制器插件。当前可配置的准入控制器插件如下。
AlwaysAdmit
允许所有请求。
AlwaysPlullImages
在启动容器之前总是尝试重新下载镜像。这对于多租户共享一个集群的场景非常有用，系统在启动容器之前可以保证总是使用租户的密钥去下载镜像。如果不设置这个控制器，则在 Node 上下载的镜像的安全性将被削弱，只要知道该镜像的名称，任何人便可以使用它们了。
AlwaysDeny
禁止所有请求，用于测试。
DenyExecOnPrivileged
已弃用，拦截所有想在 Privileged Container 上执行命令的请求。如果你的集群支持 Privileged Container，又希望限制用户在这些 Privileged Container 上执行命令，那么强烈推荐你使用它。其功能已合并到 DenyEscalatingExec 中。
DenyEscalatingExec
拦截所有 exec 和 attach 到具有特权的 Pod 上的请求。如果你的集群支持运行有 escalated privilege 特权的容器，又希望限制用户在这些容器内执行命令，那么强烈推荐你使用它。
ImagePolocyWebhook
这个插件将允许后端的一个 Webhook 程序来完成 admission controller 的功能。ImagePolicyWebhook 需要使用一个配置文件（通过 kube-apiserver 的启动参数 --admission-control-config-file 设置）定义后端 Webhook 的参数。目前是 Alpha 版本的功能。
ServiceAccount
这个插件将 ServiceAccount 实现了自动化，如果你想要使用 ServiceAccount 对象，那么强烈推荐你使用它。
SecurityContextDeny
这个插件将 Pod 中定义的 SecurityContext 选项全部失效。SecurityContext 在 Container 中定义了操作系统级别的安全设定（uid、git、capabilities、ESLinux 等）。在未设置 PodSecurityPolicy 的集群中建议启用该插件，以禁用容器设置的非安全访问权限。
ResourceQuota
用于资源配额管理目的，作用域 Namespace 上。该插件拦截所有请求，以确保在 Namespace 上的资源配额使用不会超标。推荐在 Admission Control 参数列表中将这个插件排最后一个，以免可能会被其他插件拒绝的 Pod 被过早分配资源。
LimitRanger
用于资源限制管理，作用于 Namespace 上，确保对 Pod 进行资源限制。启用该插件还会为未设置资源限制的 Pod 进行默认配置，例如为 namespace “default” 中所有 Pod 设置 0.1 CPU 的资源请求。
InitialResources
为试验性特性，是一个开发中的功能，宗旨在未设置资源请求、限制的 Pod、根据其镜像的历史资源的使用情况进行初始化的资源请求、限制设置。
NamespaceLifecycle
如果尝试在一个不存在的 namespace 中创建资源对象，则该创建请求将被拒绝。当删除一个 namespace 时，系统将会删除该 namespace 中的所有对象，包括 Pod、Service 等。
DefaultStorageClass
为了实现共享存储的动态供应，为未指定 StorageClass 或 PV 的 PVC 尝试匹配默认的 StorageClass，尽可能减少用户在申请 PVC 时所需了解的后端存储细节。
DefaultTolerationSeconds
这个插件为那些没有设置 forgiveness tolerations 并具有 notready:NoExecute 和 unreachable:NoExecut 两种 taints 的 Pod 设置默认的 “容忍” 时间，为 5min。
PodSecurityPolicy
这个插件用于在创建或修改 Pod 时决定是否根据 Pod 的 security context 和可用的 PodSecurityPolicy 对 Pod 的安全策略进行控制。
在 API Server 上设置 --admission-control 参数，即可定制需要的准入控制链，如果启用多种准入控制选项，则建议的设置如下：
Kubernetes v1.6.x
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,ResourceQuota
Kubernetes v1.8.x
--admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota
Secret 私密凭据
文档地址：
链接
