WEBKT

K8s安全加固实战：运维老鸟避坑指南

45 0 0 0

K8s安全加固实战：运维老鸟避坑指南

1. RBAC权限管理：精细化是王道

2. 网络策略：打造安全微隔离

3. 镜像安全扫描：防患于未然

4. Secret管理：保护敏感信息

5. 准入控制：最后一道防线

6. 其他安全建议

总结

K8s安全加固实战：运维老鸟避坑指南

作为一名在K8s战场上摸爬滚打多年的老兵，我深知K8s集群安全的重要性。别看K8s能帮你轻松管理容器，一旦安全防线失守，那损失可不是闹着玩的。今天，我就结合自己踩过的坑，跟大家聊聊K8s集群的安全加固，希望能帮大家少走弯路。

1. RBAC权限管理：精细化是王道

RBAC（Role-Based Access Control，基于角色的访问控制）是K8s安全的第一道防线，也是最容易被忽视的地方。很多新手直接给用户分配cluster-admin权限，图省事，但这是非常危险的！cluster-admin拥有整个集群的最高权限，一旦账号泄露，整个集群就暴露在风险之中。

正确姿势：最小权限原则

  • 分析需求： 仔细分析每个用户/服务需要访问哪些资源，以及需要执行哪些操作。例如，开发人员可能只需要查看Pod的日志，而运维人员可能需要重启Pod。

  • 创建Role和ClusterRole： 使用YAML文件定义Role和ClusterRole，明确指定允许访问的资源类型（resource）、资源名称（resourceNames）和操作（verbs）。

    		# 开发人员查看Pod日志的Role
    		apiVersion: rbac.authorization.k8s.io/v1
    		kind: Role
    		metadata:
    		  name: pod-log-reader
    		  namespace: default
    		rules:
    		- apiGroups: [""]
    		  resources: ["pods/log"]
    		  verbs: ["get", "list"]
    		 
    		# 运维人员重启Pod的ClusterRole
    		apiVersion: rbac.authorization.k8s.io/v1
    		kind: ClusterRole
    		metadata:
    		  name: pod-rebooter

rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "update", "patch"]
```

  • 创建RoleBinding和ClusterRoleBinding： 将Role和ClusterRole绑定到用户或ServiceAccount。ServiceAccount是Pod的身份标识，建议每个Pod都使用独立的ServiceAccount。

    		# 将pod-log-reader Role绑定到dev用户
    		apiVersion: rbac.authorization.k8s.io/v1
    		kind: RoleBinding
    		metadata:
    		  name: pod-log-reader-binding
    		  namespace: default
    		subjects:
    		- kind: User
    		  name: dev # 用户名，例如：dev@example.com
    		  apiGroup: rbac.authorization.k8s.io
    		roleRef:
    		  kind: Role
    		  name: pod-log-reader
    		  apiGroup: rbac.authorization.k8s.io
    		 
    		# 将pod-rebooter ClusterRole绑定到kube-system命名空间下的某个ServiceAccount
    		apiVersion: rbac.authorization.k8s.io/v1
    		kind: ClusterRoleBinding
    		metadata:
    		  name: pod-rebooter-binding

subjects:
- kind: ServiceAccount
name: my-service-account
namespace: kube-system
roleRef:
kind: ClusterRole
name: pod-rebooter
apiGroup: rbac.authorization.k8s.io
```

踩坑经验：

  • 命名空间隔离： 尽量将不同业务的Pod部署在不同的命名空间下，并使用RBAC进行隔离。这样可以避免一个业务的漏洞影响到其他业务。
  • 定期审查： 定期审查RBAC配置，确保权限分配仍然合理。人员变动或业务调整后，要及时更新权限。
  • 使用工具： 可以使用一些工具来辅助RBAC管理，例如kube-rbac-proxy，它可以将外部身份验证系统与K8s RBAC集成。

2. 网络策略：打造安全微隔离

默认情况下，K8s集群中的所有Pod都可以互相访问，这在生产环境中是不可接受的。网络策略（Network Policy）可以让你定义Pod之间的网络访问规则，实现微隔离。

正确姿势：白名单策略

  • 安装网络插件： K8s本身不提供网络策略的实现，需要安装网络插件，例如Calico、Cilium、Weave Net等。我个人比较喜欢Calico，功能强大，性能也不错。

  • 定义NetworkPolicy： 使用YAML文件定义NetworkPolicy，指定允许哪些Pod访问哪些Pod。建议采用白名单策略，即默认拒绝所有访问，只允许明确定义的访问。

    		# 只允许frontend Pod访问backend Pod
    		apiVersion: networking.k8s.io/v1
    		kind: NetworkPolicy
    		metadata:
    		  name: frontend-to-backend
    		  namespace: default

spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
```

这个NetworkPolicy只允许带有`app: frontend`标签的Pod访问带有`app: backend`标签的Pod。其他Pod都无法访问`backend` Pod。

踩坑经验：

  • 默认拒绝策略： 建议先创建一个默认拒绝所有流量的NetworkPolicy，然后再逐步添加允许的规则。这样可以避免遗漏，确保安全。

    		# 默认拒绝所有流量
    		apiVersion: networking.k8s.io/v1
    		kind: NetworkPolicy
    		metadata:
    		  name: default-deny
    		  namespace: default

spec:
podSelector: {}
ingress: []
```

  • 多命名空间策略： 可以使用namespaceSelector来定义跨命名空间的网络策略。例如，允许dev命名空间下的所有Pod访问prod命名空间下的指定Pod。
  • 监控： 部署网络策略后，要进行监控，确保策略生效，并且没有影响到正常业务。可以使用Calico的calicoctl工具来查看网络策略的执行情况。

3. 镜像安全扫描：防患于未然

容器镜像中可能存在漏洞或恶意代码，如果不进行扫描，就直接部署到集群中，可能会造成严重的安全问题。因此，镜像安全扫描是K8s安全的重要组成部分。

正确姿势：自动化扫描流程

  • 选择扫描工具： 有很多镜像安全扫描工具可供选择，例如Trivy、Clair、Anchore等。我个人比较喜欢Trivy，使用简单，扫描速度快，而且支持多种漏洞库。

  • 集成到CI/CD： 将镜像安全扫描集成到CI/CD流程中，在镜像构建完成后自动进行扫描。如果发现高危漏洞，则阻止镜像发布。

    例如，使用Jenkins和Trivy进行镜像安全扫描：

    		# Jenkins Pipeline示例
    		pipeline {
    		    agent any
    		    stages {
    		        stage('Build Image') {
    		            steps {
    		                docker build -t my-image:latest .
    		            }
    		        }
    		        stage('Scan Image') {
    		            steps {
    		                sh 'trivy image --exit-code 1 --severity HIGH my-image:latest'
    		            }
    		        }
    		        stage('Push Image') {
    		            steps {
    		                docker push my-image:latest
    		            }
    		        }
    		    }
    		}

    这个Pipeline会在镜像构建完成后，使用Trivy扫描镜像。如果发现高危漏洞，Trivy会返回非零退出码，导致Pipeline失败，阻止镜像发布。

  • 定期扫描： 除了在CI/CD流程中进行扫描，还要定期扫描已经部署到集群中的镜像。因为新的漏洞会不断被发现，即使之前的镜像没有漏洞，也可能在之后出现漏洞。

踩坑经验：

  • 漏洞忽略： 有些漏洞可能无法修复，或者修复成本太高。可以使用漏洞忽略功能，将这些漏洞排除在扫描结果之外。但要谨慎使用，确保忽略的漏洞不会对业务造成影响。
  • 自定义策略： 可以根据自己的安全需求，自定义扫描策略。例如，只扫描特定类型的漏洞，或者只扫描特定目录下的文件。
  • 漏洞情报： 关注漏洞情报，及时了解新的漏洞信息。可以订阅漏洞邮件列表，或者使用漏洞情报平台。

4. Secret管理：保护敏感信息

K8s Secret用于存储敏感信息，例如密码、API Token、证书等。如果Secret管理不当，可能会导致敏感信息泄露。

正确姿势：加密存储，权限控制

  • 加密存储： 默认情况下，K8s Secret以Base64编码存储在etcd中，这并不是真正的加密。要启用Secret加密，需要在kube-apiserver中配置加密Provider。常用的加密Provider有AES-CBC、KMS等。

    例如，使用AES-CBC加密Secret：

    1. 生成AES密钥：

      head -c 32 /dev/urandom | base64 > encryption-key.txt

    2. 配置kube-apiserver：

      在kube-apiserver的配置文件中添加以下内容：

      		apiVersion: apiserver.config.k8s.io/v1
      		kind: EncryptionConfiguration
      		resources:
      		  - resources:
      		      - secrets
      		    providers:
      		      - aescbc:
      		          keys:
      		            - name: key1
      		              secret: <base64 encoded encryption key>
      		      - identity:

      将<base64 encoded encryption key>替换为encryption-key.txt文件的内容。

    3. 重启kube-apiserver：

      重启kube-apiserver使配置生效。

  • 权限控制： 使用RBAC控制Secret的访问权限，只允许需要的用户/服务访问Secret。

  • 使用Secret管理工具： 可以使用Secret管理工具来简化Secret的管理，例如HashiCorp Vault、Sealed Secrets等。这些工具可以提供更高级的功能，例如Secret版本控制、Secret自动轮换等。

踩坑经验：

  • 避免明文存储： 绝对不要将敏感信息明文存储在配置文件或代码中。应该使用Secret来存储敏感信息。
  • 定期轮换： 定期轮换Secret，可以降低Secret泄露的风险。可以使用Secret管理工具来自动轮换Secret。
  • 审计： 启用审计日志，监控Secret的访问情况。如果发现异常访问，要及时处理。

5. 准入控制：最后一道防线

准入控制器（Admission Controller）是K8s的最后一道防线，它可以在Pod创建之前拦截请求，并根据配置的策略进行验证或修改。准入控制器可以用于实现很多安全策略，例如：

  • 强制使用镜像仓库： 强制Pod使用指定的镜像仓库，防止使用未授权的镜像。
  • 限制资源使用： 限制Pod的资源使用量，防止资源耗尽攻击。
  • 添加安全上下文： 自动为Pod添加安全上下文，例如设置用户ID、组ID、capabilities等。

正确姿势：根据需求选择准入控制器

  • 了解准入控制器类型： K8s提供了多种准入控制器，例如AlwaysPullImages、PodSecurityPolicy、ResourceQuota等。要根据自己的需求选择合适的准入控制器。
  • 配置准入控制器： 使用YAML文件配置准入控制器，指定策略和规则。
  • 使用第三方准入控制器： 如果K8s自带的准入控制器无法满足需求，可以使用第三方准入控制器，例如OPA Gatekeeper、Kyverno等。

踩坑经验：

  • 配置错误： 准入控制器的配置非常复杂，容易出错。配置错误可能会导致Pod无法创建，影响业务。因此，在配置准入控制器之前，要仔细阅读文档，并进行充分的测试。
  • 性能影响： 准入控制器会增加Pod创建的延迟，可能会对性能造成影响。因此，要选择性能良好的准入控制器，并优化配置。
  • 维护： 准入控制器需要定期维护，例如更新策略、升级版本等。如果维护不当，可能会导致安全漏洞。

6. 其他安全建议

除了以上几点，还有一些其他的安全建议：

  • 升级K8s版本： 及时升级K8s版本，可以修复已知的安全漏洞。
  • 使用TLS加密： 使用TLS加密所有网络流量，包括Pod之间的流量和客户端与API Server之间的流量。
  • 启用审计日志： 启用审计日志，监控集群中的所有操作。可以及时发现异常行为。
  • 限制API Server访问： 限制API Server的访问，只允许授权的用户/服务访问API Server。
  • 监控集群安全： 使用安全监控工具，监控集群的安全状态。可以及时发现安全问题。

总结

K8s安全是一个复杂而重要的课题，需要不断学习和实践。希望本文能帮助大家更好地理解K8s安全，并采取有效的措施来保护自己的集群。记住，安全无小事，防患于未然！

作为一名老鸟，我希望这些经验能帮助你避免一些不必要的坑，祝你的K8s集群安全稳定！

K8s老司机 Kubernetes安全K8s加固容器安全

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9783