夯实地基 - SRE 必须掌握的基础设施安全原则-CFANZ编程社区

夯实地基 - SRE 必须掌握的基础设施安全原则

核心原则：最小权限原则 (Principle of Least Privilege - PoLP)

最小权限原则 (PoLP) 是信息安全领域的一项基本且至关重要的指导原则。它的核心思想是：任何用户、进程、程序或系统组件，都只应被授予其完成预定功能所必需的、最少的权限集合，并且这些权限的授予时间也应尽可能短。

为何 PoLP 对 SRE 如此关键？

减小薄弱面和爆炸半径：

如果某个账户或组件被攻破，PoLP 可以极大地限制不法人员能够造成的损害。一个拥有 admin 超级权限的账户被盗，后果可能是灾难性的；而一个只拥有读取特定日志权限的账户被盗，其潜在危害则小得多。

最小化意外损害 (Minimizes Accidental Damage)：

即便是善意的用户或设计良好的自动化脚本，也可能因为权限过大而无意中做出超出预期的、破坏性的更改。PoLP 有助于防止这类“好心办坏事”的情况。

提升可审计性与合规性 (Improves Auditability & Compliance)：

当权限被严格控制和细致划分后，追踪“谁在何时对什么资源做了什么操作”变得更加容易，也更便于满足合规性审计的要求。

SRE 的实践应用:

服务账户 (Service Accounts)：为应用程序（例如，Prometheus 抓取指标、CI/CD 流水线部署应用）创建专用的服务账户时，务必精确授予其所需的最小 API 权限。
用户访问: 配置用户对服务器、云平台控制台、Kubernetes 集群等的访问权限时，严格按需分配。
自动化工具: 自动化脚本或工具也应以最小权限运行。
定期审查: 定期回顾和清理不再需要的或权限过大的账户和授权。

简单来说，PoLP 就是确保每个实体只拥有“完成其工作所必需知道的信息 (Need-to-know)”和“完成其工作所必需执行的操作 (Need-to-do)”的权限。

身份与访问管理：IAM 与 RBAC

身份与访问管理 (Identity and Access Management - IAM) 是一个涵盖了策略、流程和技术的大框架，其目标是确保正确的实体（人或程序）能够以恰当的方式访问正确的资源。

IAM 通常包含两大核心功能：

认证 (Authentication - AuthN - “你是谁？”)：验证用户、服务或设备的身份。常见方式有：

用户名/密码
SSH 密钥
API 令牌 (Tokens)
双因素/多因素认证 (MFA)
客户端证书 (mTLS)

授权 (Authorization - AuthZ - “你能做什么？”)：在身份通过认证后，确定该身份被允许执行哪些操作、访问哪些资源。PoLP 正是在授权阶段被强制执行的。

Kubernetes RBAC (基于角色的访问控制) 是一个典型的授权实现：

我们在之前的 Kubernetes 安全篇中已经介绍过 RBAC，这里从 SRE 如何实施的角度再回顾一下：

核心组件: User, Group, ServiceAccount (主体); Role (命名空间级权限集合), ClusterRole (集群级权限集合); RoleBinding (命名空间级绑定), ClusterRoleBinding (集群级绑定)。
SRE 实施场景举例:

场景 1：CI/CD 流水线的 ServiceAccount

需求: 需要在一个特定的命名空间 (app-ns) 中部署应用（创建/更新 Deployment, Service, ConfigMap）。
**实施 **:

创建一个 ServiceAccount (例如 cicd-sa) 在 app-ns。
定义一个 Role (例如 app-deployer-role) 在 app-ns，授予对 deployments, services, configmaps 资源的 create, get, list, watch, update, patch, delete 权限。
创建一个 RoleBinding，将 cicd-sa 与 app-deployer-role 绑定起来。

场景 2：监控系统的 ServiceAccount

需求: Prometheus 需要在整个集群范围内发现并抓取 Pods, Services, Endpoints, Nodes 的指标。
**实施 **:

创建一个 ServiceAccount (例如 prometheus-sa) 在 monitoring 命名空间。
定义一个 ClusterRole (例如 metrics-reader-clusterrole)，授予对 pods, services, endpoints, nodes 等资源的 get, list, watch 权限。
创建一个 ClusterRoleBinding，将 prometheus-sa 与 metrics-reader-clusterrole 绑定。

场景 3：On-call SRE 用户组

需求: 需要对生产命名空间中的大多数资源拥有只读权限以便排障，但对某些特定操作（如重启 Pod）有有限的写权限。
实施: 定义不同的 Role（例如 prod-viewer-role, pod-restarter-role），然后将 SRE 用户组通过 RoleBinding 绑定到这些 Role。

审计 RBAC: 可以使用 kubectl auth can-i <verb> <resource> --as <user/sa> -n <namespace> 来检查特定主体是否有权限执行某操作。也有一些第三方工具可以帮助审计 RBAC 配置的合规性和潜在风险。

云平台的 IAM: SRE 在云环境中（如 AWS IAM, GCP IAM, Azure RBAC）同样需要大量管理 IAM 角色和策略，以控制对云资源（虚拟机、存储桶、数据库实例、Kubernetes 控制平面本身等）的访问。PoLP 原则在这里同样至关重要。

网络安全基础：隔离与控制

网络安全是纵深防御体系中的关键一层。SRE 需要关注以下基础的网络安全控制措施：

A. 防火墙与安全组 (云环境)

作用: 在实例（虚拟机）或子网级别，基于 IP 地址、端口和协议来控制入站和出站的网络流量。
安全组 (Security Groups - AWS/GCP) / 网络安全组 (Network Security Groups - NSG - Azure): 充当有状态的虚拟防火墙，应用于虚拟机实例。SRE 需要配置规则，仅允许必要的流量。例如：

只允许来自特定堡垒机 IP 的 SSH (TCP/22) 流量。
只允许来自特定负载均衡器 IP 的 HTTPS (TCP/443) 流量。
只允许来自应用服务器 IP 段的数据库端口 (如 TCP/3306) 流量。

网络 ACL (NACLs - AWS): 无状态的防火墙，作用于子网级别，提供额外的网络隔离层。
**SRE 的任务 **: 定义和维护这些防火墙规则，确保它们严格遵循 PoLP（只开放必要的端口给必要的源IP）。

B. Kubernetes `NetworkPolicy`

我们在 Kubernetes 安全篇也介绍过，这里再次强调其在基础设施安全中的作用。

作用: 在 Kubernetes 集群内部，实现 Pod 之间的 L3/L4 网络隔离。
**SRE 实施场景 **:

默认拒绝策略 (Default Deny): 为一个命名空间创建一个默认策略，拒绝所有入站和出站流量，然后逐步添加明确允许的策略。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: secure-production
spec:
  podSelector: {} # 选择命名空间中的所有 Pod
  policyTypes:
  - Ingress
  - Egress
# 没有定义 ingress 或 egress 规则，意味着默认拒绝所有

允许特定流量: 例如，允许 frontend Pod 访问 backend Pod 的特定端口。
出站控制 (Egress Control): 限制 Pod 能够连接到哪些外部服务或 IP 地址。

SRE 角色: 与应用团队合作，规划、定义和实施合适的 NetworkPolicy。这需要 CNI 网络插件支持（如 Calico, Cilium）。

C. 堡垒机 / 跳板机 (Bastion Hosts / Jump Boxes)

作用: 一个经过安全加固的服务器，作为访问内部网络资源（如没有公网 IP 的生产服务器、数据库）的唯一、受控的入口点。
SRE 角色: 负责搭建、安全加固（例如，最小化安装、禁用不必要服务、定期打补丁、强密码/密钥策略、启用 MFA）、监控堡垒机，并严格控制其上的用户访问权限和审计日志。

总结

最小权限原则是所有访问控制的基础。IAM (及 K8s RBAC) 提供了“谁能对什么做什么”的框架。而网络安全控制（如防火墙、安全组、NetworkPolicy、堡垒机）则在基础设施层面建立了必要的边界和隔离。在下一篇中，我们将聚焦于另一个对安全和运维可靠性都至关重要的主题：“密钥与凭证管理 (Secrets Management)”，探讨如何安全地处理密码、API 密钥、证书等敏感信息。敬请期待！