/tags/kube-security/ Recent content in Kube Security on RenovZ's Notes Hugo -- gohugo.io en-us Sun, 07 Apr 2024 20:03:24 +0800 /posts/authorization/ Sun, 07 Apr 2024 20:03:24 +0800 /posts/authorization/ kubernetes 内置 RBAC，ABAC，Node Authorization 等授权模式，然后使用kube-apiserver --authorization-mode=<AUTH MODE>,RBAC开启对应的授权模式，其中 RBAC 是必选项。 RBAC 基于角色的访问控制，通过集群管理员指定用户拥有的权限，使用时经过授权模块赋予对应的权限。 支持权限的降级，但不支持权限的升级，如 RoleBinding（作用域为 namespace）可以绑定到 ClusterRole，但是不能将 ClusterRoleBinding（作用域为 cluster）绑定到 Role。 对于普通用户名或用户组的限制，其中前缀是system:为 kubernetes 系统保留的，禁止用户使用前缀为此的用户名称或组名称。 对于服务账户和服务账户组，分别需要包含system:serviceaccount:和system:serviceaccounts:前缀。 对于需要修改用户或组的 RoleBinding 或者 ClusterRoleBinding，系统不支持修改，需要删除后重新添加。 默认的 Roles 和 RoleBindings 对集群默认角色、名称、以及绑定关系的修改，都将可能导致集群无法工作，需要格外小心。 集群中以system:为前缀的，用以标识对应资源是直接由集群控制面管理的。 所有默认的 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults标签 自动协商机制保证，每次集群启动时，kube-apiserver 都会更新默认 ClusterRole 以添加各类缺失的权限，并更新 ClusterRoleBinding 以添加各类缺失的主体，可修复一些不小心发生的修改，并有助于保证角色和角色绑定在新的发行版中保持最新状态。 kube-apiserver 发现角色 默认的角色绑定赋予所有人（包括匿名用户）可以访问对于被集群认为是安全公开的 API，如果要禁用匿名用户访问可以配置kube-apiserver --anonymous-auth=false。 默认 ClusterRole 默认 ClusterRoleBinding 说明 system:basic-user system:authenticated 组 允许用户以只读的方式去访问他们自己的基本信息。在 v1.14 之前，默认也绑定 system:unauthenticated system:discovery system:authenticated 组 允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。v1.14 之前，默认也绑定 system:unauthenticated system:public-info-viewer system:authenticated, system:unauthenticated 组 允许对集群的非敏感信息进行只读访问，此角色在 v1. /posts/admission-controllers/ Sun, 07 Apr 2024 12:22:39 +0800 /posts/admission-controllers/ 准入控制器是一段代码，会在请求通过认证和授权之后、对象被持久化之前拦截到达 kube-apiserver 的请求。 准入控制器可以执行 Validating 和 Mutating 操作。准入控制器限制创建、删除、修改对象的请求，也可以阻止自定义 verbs，如通过 api 代理服务器连接到 Pod 的请求。准入控制器不能阻止 get、watch 或 list 对象的请求。 有 2 个特殊的准入控制器：MutatingAdmissionController 和 ValidatingAdmissionController，分别执行变更和验证准入控制 Webhook。 准入控制阶段 运行 MutatingAdmissionControl 运行 ValidatingAdmissionControl 某些 AdmissionController 即是 MutatingAdmissionController，又是 ValidatingAdmissionController。 如果某个请求在 2 个阶段的其中一个被拒绝，则整个请求立即被拒绝，并返回错误。 准入控制器有其他副作用，将相关资源作为请求处理的一部分进行变更。如增加资源配额。任何一个准入控制器都无法确定其他准入控制器的需求，只有当请求符合所有的准入控制器的要求，才会被 kube-apiserver 正确处理。 启用准入控制器 kube-apiserver --enable-admission-plugins=NamespaceLifeCycle,LimitRanger ... 关闭准入控制器 kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... 默认启用的准入控制器 CertificateApproval CertificateSigning CertificateSubjectRestriction DefaultIngressClass DefaultTolerationSeconds LimitRanger MutatingAdmissionWebhook NamespaceLifeCycle PersistentVolumeClaimResize PodSecurity Priority ResourceQuota ServiceAccount StorageObjectInUseProtection TaintNodesByCondition ValidatingAdmissionPolicy ValidatingAdmissionWebhook 每个准入控制器的作用 LimitRanger: 监测传入的请求，确保不会违反 Namespace 中 LimitRange 对象所设置的任何约束；还可以用于将默认资源配额应用到没有设定资源配额的 Pod NamespaceLifeCycle：会禁止在一个正在被删除的 Namespace 中创建新对象，并确保针对不存在的 Namespace 的请求被拒绝；会禁止删除系统中的保留命名空间：default,kube-system,kube-public 准入控制器列表 推荐的准入控制器 /posts/%E8%AF%81%E4%B9%A6%E4%B8%8E%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%90%8D%E8%AF%B7%E6%B1%82/ Sun, 07 Apr 2024 10:10:46 +0800 /posts/%E8%AF%81%E4%B9%A6%E4%B8%8E%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%90%8D%E8%AF%B7%E6%B1%82/ kubernetes 证书和 trust bundle API 可以通过为 kube-apiserver 的客户端提供编程接口，实现X.509证书的请求并获取证书颁发机构的自动化制备。 证书签名 etcd 不会保存签名请求，相应的会有以下几种状态： 已签发的请求：会在 1 个小时后自动被垃圾回收器删除 拒绝的请求：会在 1 个小时后自动被垃圾回收器删除 失败的请求：会在 1 个小时后自动被垃圾回收器删除 所有的请求：已签发证书会在失效以后自动被垃圾回收器删除 Signer 任何要在特定集群以外提供的签名者都应该提供关于签名者工作方式的信息。 信任分发：信任锚点（CA 证书或证书包） 许可的主体 许可的 x509 扩展：包括 IP subjectAltNames，DNS subjectAltNames, Email subjectAltNames, URL subjectAltNames 等 许可的/扩展的密钥用途 过期时间/证书有效期：可以由签名者确定、管理员配置，或者 CSR 请求中spec.expirationSeconds字段指定 允许/不允许 CA 位：若 CSR 包含一个签名者并不允许的 CA 证书时，相应的应对手段 内置的 Signer kubernetes.io/kube-apiserver-client 签名的证书将被 kube-apiserver 视为客户端证书，不会被 kube-controller-manager 自动批准 kubernetes.io/kube-apiserver-client-kubelet 签名的证书将被 kube-apiserver 视为 kubelet 的客户端证书，可以被 kube-controller-manager 自动批准 kubernetes.io/kubelet-serving 签名的证书将被视为有效的 kubelet 服务端证书，不会被 kube-controller-manager 自动批准 kubernetes. /posts/kube-apiserver-bypass-risks/ Sat, 06 Apr 2024 17:26:20 +0800 /posts/kube-apiserver-bypass-risks/ kube-apiserver 是外部与集群交互的主要入口，提供了几种关键的内置安全控制，如审计日志和准入控制器。但还有一些方式可以绕过这些安全控制从而修改集群的配置或内容。 以下这些方式需要适当的被限制。 静态 Pod 每个节点上的 kubelet 会加载并直接管理集群中存储在指定目录中或从指定 URL 获取的静态 Pod 清单。kube-apiserver 不管理这些静态 Pod。对该位置具有写入权限的攻击者可以修改从该位置加载的静态 Pod 的配置，或引入新的静态 Pod。 静态 Pod 被限制访问 kube-apiserver 中的其他对象。如不能将静态 Pod 配置为从集群挂载 Secret。但是这些 Pod 可以执行其他安全敏感的操作，如使用hostPath直接挂载宿主机节点的文件目录. 默认情况下，kubelet 会创建一个 Mirror Pod，以便静态 Pod 在 kube-apiserver 中可见。但是如果攻击者在创建 Pod 时使用了无效的名字空间名称，则该 Pod 将在 kube-apiserver 中不可见，只能通过对受影响主机有访问权限的工具发现。 如果静态 Pod 无法通过准入控制，kubelet 不会将 Pod 注册到 kube-apiserver 中，但该 Pod 仍然在节点上运行。 Mitigations 仅在节点需要时启用 kubelet 静态 Pod manifest 功能 如果一个节点使用静态 Pod 功能，限制它的文件系统访问权限，即仅配置需要访问的目录或 URL 限制对 kubelet 配置参数和文件的访问，以防止攻击者通过设置静态 Pod 访问的文件系统路径或 URL 定期审计并集中报告所有对托管静态 Pod manifest 文件和 kubelet 配置文件的目录或 Web 存储位置的访问 kubelet API kubelet 提供了一个 HTTP API，一般是 TCP:10250，在某些 kubernetes 发行版中，API 也可能暴露在 control-plane-panel 节点上。对 API 的直接访问允许公开有关运行在节点上的 Pod、这些 Pod 的日志以及在节点上运行每个容器中执行命令的信息。 /posts/authentication-mechanisms/ Sat, 06 Apr 2024 11:17:29 +0800 /posts/authentication-mechanisms/ 关于以下几种身份验证机制的生产环境中使用的利弊分析与官方建议 X.509 客户端证书身份认证 (不推荐) 客户端证书不能被单独撤销，直到证书过期 如果证书需要被设置为无效，需要重新生成证书颁发机构的密钥，会导致集群不可用 集群中没有客户端证书的永久记录，因此无法跟踪监控使用证书的用户 用户客户端证书认证的私钥无法收到密码保护，任何能够读取包含密钥文件的人都可以使用 使用客户端证书身份认证需要直接连接 kube-apiserver，没有中间跳板节点的话，可能会使网络结构变得复杂化，如网络拓扑可能需要重新规划，安全性也需要重新考虑，维护和管理负担，扩展性会变差 客户端证书的 O（Organization）中嵌入了组数据，用户的组成员资格在证书的生命周期内无法更改，意味着一旦用户获得了 X.509 客户端证书，这个用户的组成员资格将在证书有效期内保持不变，换句话说，用户被分配到的组信息是固定的，无法通过更改证书来改变用户的组成员资格，这样做缺乏灵活性，权限管理复杂性会提升，安全性隐患，难以追踪和审计 静态 Token 文件 (不推荐) 凭据信息被以明文形式保存在磁盘上，增加了安全性风险 改变任何凭据都需要重启 kube-apiserver，引发可用性风险 没有可用的机制能让用户轮换他们的凭据，如果要轮换凭据，集群管理员需要更改在磁盘上的 Token，然后在下发给用户 没有锁定机制去阻止暴力攻击 引导 tokens (不推荐) 它们固定了不适合一般使用的硬编码组成员资格，因此不适用于用户认证目的 手动生成引导令牌可能导致弱令牌，攻击者可以猜测到，会带来安全风险 没有锁定机制来防止暴力攻击，这使得攻击者容器猜测或破解令牌 ServiceAccount secret tokens (不推荐) 在 kubernetes < 1.23 版本中，是默认选项，供集群中的工作负载进行身份认证。但是这种方式正在被TokenRequest API令牌替换，官方也不建议在生产环境中使用 不能设置过期时间，而是会在相关的服务账户被删除之前一直保持有效 身份验证令牌对于在定义它们的命名空间中读取密钥的任何集群用户都是可见的 服务账户无法被添加到任意组中，导致在使用时复杂化了 RBAC 管理 TokenRequest API tokens (不推荐) 可生成短期凭据，用于服务对 kube-apiserver 或第三方系统进行身份认证的有用工具，官方也不建议用于生产环境，因为没有可用的吊销方法，并且以安全的方式将凭据分发给用户可能也有挑战。 当使用 TokenRequest 令牌进行身份认证时，建议实现短期生命周期，以减少受到损害的令牌带来的影响。 OIDC 令牌身份认证 (推荐) 官方支持使用 OpenID Connect 令牌身份认证，将外部身份验证服务与 kube-apiserver 集成。使用 OIDC 时，需要考虑以下加固措施： 安装在集群中以支持 OIDC 身份认证的软件应该与一般工作负载隔离，因为它将以高权限运行 一些 kubernetes 托管服务对可以使用的 OIDC 提供者有限制 与 TokenRequest 令牌一样，OIDC 令牌的生命周期应该较短，以减少受到损害的令牌产生的影响 Webhook token 身份认证 (中立) 是将外部身份认证服务提供者集成到 kubernetes 中的另一种选项。该服务可以集成在集群内部或外部运行，用于进行身份认证。该机制的使用性取决于用于身份认证服务的软件，并且有一些 kubernetes 特定的考虑因素。 /posts/kube-api-%E8%AE%BF%E9%97%AE%E6%8E%A7%E5%88%B6/ Fri, 05 Apr 2024 19:20:16 +0800 /posts/kube-api-%E8%AE%BF%E9%97%AE%E6%8E%A7%E5%88%B6/ 身份认证策略 kubernetes 通过身份认证插件利用客户端证书、持有者令牌或身份代理来认证 API 请求的身份。HTTP 请求发给 kube-apiserver 时，插件会将以下属性关联到请求本身： 用户名 用户 ID 用户组：一组字符串，用来标明用户是哪些命名的用户组集合的成员，如系统组 system:masters（这个组的使用有一定的风险），这里只是为了说明 附加字段：一组额外的 KV 映射，用来保存一些认证组件可能觉得有用的额外价值 所有属性值对于身份认证系统都是非透明的，只有被认证组件解释过之后才有意义，才会被 kubernetes 集群所识别。可以同时启用多种身份认证方法，并且通常至少会有 2 种： 针对服务账号使用的令牌 针对普通人类用户的身份认证 认证组件的执行顺序是不确定的，对于完成身份认证的用户，system:authenticated 组都会被添加到用户的组属性中。 X.509 客户端证书 通过 TLS 的非对称加密完成的双向身份认证，使用--client-ca-file=<client-ca-file>，参考证书管理 静态令牌 这种方式就跟我们不同服务之间内部交互，直接使用一个随机字符串去互相认证类似。目前令牌会长期有效，且 kube-apiserver 不重启的情况下无法更新令牌，使用--token-auth-file=<token-file>。当使用 HTTP 客户端执行身份认证时，http 请求需要携带一个Authorization: Bearer <token string>的头信息。 启动引导令牌 像执行 kubeadm join 中使用的 token 就是这个，这个主要用于平滑启动引导集群，这些令牌以 Secret 的形式保存在 kube-system 命名空间中，可以被动态管理和创建。TokenCleaner控制器能够在启动引导令牌过期时将其删除。 它也被设计成可通过 RBAC 策略，结合 kubelet TLS 启动引导系统进行工作。这个令牌被定义成一个特定的 Secret 类型bootstrap.kubernetes.io/token，并存在于 kube-system 命名空间中。这些 secret 会被 kube-apiserver 启动引导认证组件（Bootstrap Authenticator）读取，TokenCleaner能够删除过期的启动引导令牌，也被用来在节点发现的过程中使用的一个特殊的 ConfigMap 对象，BootstrapSigner控制器也会使用这个 ConfigMap。参考Bootstrap Tokens /posts/pod-%E5%AE%89%E5%85%A8%E6%80%A7/ Fri, 05 Apr 2024 11:53:18 +0800 /posts/pod-%E5%AE%89%E5%85%A8%E6%80%A7/ 安全标准 Privileged 不受限制的策略，此类 Pod 权限较高，通常为一些系统级别或基础设施级别的工作负载 Baseline 限制性最弱的策略，禁止已知的特权提升 HostProcess, windows related (v1.26 stable) Restricted Fields spec.securityContext.windowsOptions.hostProcess spec.containers[*].securityContext.windowsOptions.hostProcess spec.initContainers[*].securityContext.windowsOptions.hostProcess spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess Allowed Values undefined/nil false Host Namespaces: Sharing the host namespaces must be disallowed. Restricted Fields spec.hostNetwork spec.hostPID spec.hostIPC Allowed Values undefined/nil false Privileged Containers: Privileged Pods disable most security mechanisms and must be disallowed. Restricted Fields spec.containers[*].securityContext.privileged spec.initContainers[*].securityContext.privileged spec.ephemeralContainers[*].securityContext.privileged Allowed Values undefined/nil false Capabilities: Adding additional capabilities beyond those listed below must be disallowed.