Amazon AWS 概念及相关操作步骤

发表于 更新于 上层目录 ， 阅读次数：

AWS 虚拟私有云 VPC

在进入具体的网络配置前，必须理解 AWS 的地理隔离：

  • 区域 (Region) ：地理上的独立区域（如新加坡、弗吉尼亚）。区域之间完全隔离。

  • 可用区 (Availability Zone, AZ) ：一个区域内由多个物理机房组成。AZ 之间通过高速、低延迟光纤连接。高可用架构必须跨 AZ 部署。跨 AZ 之间的流量需要付费。

VPC 是你在 AWS 云中的逻辑隔离网络。你可以完全控制其 IP 地址范围、子网、路由表和网络网关。

核心组件：

  • CIDR 范围 ：你为 VPC 定义的私有 IP 地址块（如 10.0.0.0/16 ）。

  • 子网 (Subnets) ：将 VPC 划分为更小的网段。子网必须位于特定的可用区内。

  • 公有子网 (Public Subnet) ：路由指向互联网网关 (IGW)，实例可以有公网 IP。

  • 私有子网 (Private Subnet) ：没有指向 IGW 的直接路由，通常通过 NAT 网关 访问外网 。

公有子网 和 私有子网 在配置上几乎一摸一样，唯一区别在于： 该子网关联的路由表（Route Table）中默认路由（0.0.0.0/0）是如何配置的。

  • 公有子网 (Public Subnet) 其路由表中默认路由（0.0.0.0/0）指向 互联网网关 (Internet Gateway, ID 格式通常为 igw-xxxxxx) 。由于它直接连接到互联网大门，且子网内的实例拥有公网 IP，因此外部用户可以主动访问它，它也可以直接访问外部。
  • 私有子网 (Private Subnet) 其路由表中默认路由（0.0.0.0/0）指向 NAT 网关 (NAT Gateway, ID 格式通常为 nat-xxxxxx)，或者干脆没有任何去往外网的路由 。它没有直通互联网的大门。它通过 NAT 网关（单向出口）实现“能出不能进”的效果。
    下图所示子网为 公有子网

  • 路由表（Route Tables） 分为主路由表和自定义路由表
    • 主路由表（Main route table） 随 VPC 自动生成，它控制未与任何其他路由表显式关联的所有子网的路由，也就是 VPC 中的默认路由。
    • 自定义路由表 为新建的路由表。
    • 一个子网只能关联一个路由表，一个路由表可以关联多个子网

流量如何进出

VPC 与外界互联网通信可以使用以下方式：

组件 作用 流量方向 用法说明｜
Internet Gateway (IGW，互联网网关) 允许 VPC 连接互联网。 双向 (In/Out) 实例必须分配公网 IP 或弹性 IP (EIP)
NAT Gateway (NAT 网关) 允许私有实例上外网，但防止外部主动连接。 单向 (Outbound only) 仅需私有 IP
VPC Peering （对等连接） 连接两个不同的 VPC，使其像在一个网络内通信。 跨 VPC
Transit Gateway 充当“中央枢纽”，连接数千个 VPC 和本地网络。 复杂网络拓扑
Virtual Private Gateway 用于建立 VPN 连接。 混合云

部署 NAT Gateway 网关并关联子网

通过 NAT Gateway 可以实现子网中的实例的对外互联网出口 IP 都是 NAT Gateway 绑定的 EIP，子网中的实例对互联网不可见。NAT Gateway 典型使用场景：

  • 为了安全，生产环境通常将 EKS 工作节点、RDS 数据库 或 缓存服务器（Redis） 放在私有子网中，这些资源不需要（也不应该）被互联网直接访问。
  • 应用需要调用外部服务（如支付网关、银行接口或第三方 API）时，对方的防火墙通常需要你提供一个白名单 IP。由于 EKS 节点是动态变化的，IP 并不固定。
  • 减少受攻击面，防止外部扫描。

以下为创建 NAT Gateway 并关联子网的相关步骤：

正确的整体架构
VPC
├── Public Subnet
│   ├── NAT Gateway（有 EIP）
│   └── Route Table (Public RT)
│       └── 0.0.0.0/0 → Internet Gateway
│
└── Private Subnet
    ├── EC2 / ECS / EKS Node
    └── Route Table (Private RT)
        └── 0.0.0.0/0 → NAT Gateway

关键点：

  • NAT Gateway 必须在公有子网
  • 私有子网的默认路由指向 NAT Gateway

  1. 确认 Public Subnet 存在

    VPC 默认的 Main Route Table 已经满足这个条件，其默认网关为 Internet Gateway

  2. 创建 NAT Gateway

    在 NAT gateways 标签页面中，点击 Create NAT gateway ， Connectivity type 选择 Public ， Elastic IP (EIP) association 选择 手动分配 EIP（Manual）

    创建完成后，状态应为 Available 。在路由表（Route Tables）中，这时会多一个路由表，其 Edge associations（边缘关联） 关联到了刚刚创建的 NAT Gateway

  3. 创建一个新的子网（私有、Private Subnet）

    在 VPC → Subnets → Create subnet 标签页面中创建新的子网， 不要勾选 Auto-assign public IPv4 ，如此处于此子网中的实例，不会为其分配公网地址

  4. 创建 Private Route Table

    在 VPC → Route tables → Create route table 标签页面中创建新的路由表，本示例名为 private-rt

  5. 配置路由规则

    选择刚刚创建的新路由表 private-rt，在 Routes 中 编辑路由（Edit Routes） ，添加一条路由规则： 

    | Destination | Target          |
    | ----------- | --------------- |
    | 0.0.0.0/0   | NAT Gateway |

  6. 关联 Private Subnet

    选择刚刚创建的新路由表 private-rt，在 Subnet associations(子网关联) 中 Edit subnet associations（编辑子网关联） ，选择目标子网进行关联

  7. 最终的 VPC 整体路由可以在 VPC 的 Resource map 中进行检查

EKS 中的授权机制

Kubernetes 原生提供 RBAC（Role-Based Access Control） 来控制集群中的 用户和服务账户（ServiceAccount） 对资源的访问权限。

对象 描述
Role 命名空间级别（Namespace）权限，指定某个命名空间内允许的操作和资源类型。
ClusterRole 集群级别权限，可以跨命名空间使用。
RoleBinding 将 Role 绑定到一个用户或 ServiceAccount。
ClusterRoleBinding 将 ClusterRole 绑定到一个用户或 ServiceAccount。

核心字段

  • apiGroups ：资源所属 API 组，例如 "" 代表 core API 。

  • resources ：允许访问的资源类型，如 pods、deployments。

  • verbs ：允许的操作，如 get, list, create, delete 。

RBAC 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: my-serviceaccount
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

  • RBAC 控制的是 Kubernetes 资源访问权限 。

  • RBAC 对象绑定的是 Kubernetes 用户或 ServiceAccount，而不是 AWS IAM 用户 。

概念 全称 解决的问题 作用范围
RBAC Role-Based Access Control 决定 “用户/进程” 在 K8s 集群内能做什么（如：查看 Pod） K8s 集群内部
Role Kubernetes Role RBAC 的一部分，定义一组具体的集群内操作权限 命名空间 (Namespace)
IRSA IAM Roles for Service Accounts 决定 “Pod 里的应用” 对 AWS 外部资源（如 S3/RDS）的访问权限 AWS 云环境

AWS IAM Role 是 AWS 层面的权限机制，用于授权 AWS 资源访问，例如 S3、DynamoDB、Secrets Manager 等。

AWS IAM Role 的特点：

  • 可以被 IAM 用户、服务或 EC2/EKS Pod 假设（Assume）。

  • 权限通过 IAM Policy 定义。

AWS IAM Role 在 EKS 中的应用:

  • 管理集群本身访问 AWS 资源，例如节点组（NodeGroup）访问 S3。

  • 可以通过 IAM 用户/Role 管理集群级别的操作权限，例如 eks:DescribeCluster 。

💡 核心点：IAM Role 本身无法直接控制 Kubernetes 资源，它管理的是 AWS 资源访问。

IRSA（IAM Roles for Service Accounts） 是 AWS EKS 引入的将 Kubernetes ServiceAccount 与 AWS IAM Role 绑定，实现 Pod 级别的 AWS 权限控制的机制。其大致原理如下：

  • EKS 集群开启 OIDC Provider
  • 创建 IAM Role 并信任该 OIDC Provider
  • Role 上定义 IAM Policy（如访问 S3）
  • Kubernetes ServiceAccount 指定注解 eks.amazonaws.com/role-arn。
  • Pod 使用该 ServiceAccount 时自动获取 Role 权限

实践建议：

  • 不要在 Pod 内放 AWS AccessKey，使用 IRSA。

  • 最小权限原则：

    • RBAC：只给 Pod 或用户真正需要的 Kubernetes 权限。

    • IAM Role / IRSA：只给访问 AWS 资源的最小权限。

  • 多集群管理：可以通过 ClusterRole + RoleBinding 管理跨命名空间权限。

  • 审计：

    • 使用 CloudTrail 监控 IRSA 调用。

    • Kubernetes API Server 日志审计 RBAC 权限。