1. 项目概述：通过代码为AWS EB环境中的EC2实例添加用户

在AWS Elastic Beanstalk（EB）环境中管理EC2实例时，直接登录服务器手动添加用户的方式既低效又难以维护。最近我在一个需要批量部署开发环境的项目中，实现了通过代码方式自动创建并配置EC2用户的操作方案。这种方法特别适合需要动态扩展实例或保持基础设施一致性的场景。

传统方式下，管理员需要SSH连接到每台EC2实例，执行 useradd 等命令。但在EB这类PaaS服务中，实例可能随时被重建或替换，手动操作显然不可行。通过 .ebextensions 配置文件和UserData脚本的组合，我们可以在实例启动阶段自动完成用户创建、权限分配和SSH密钥配置的全流程。

2. 核心方案设计

2.1 技术选型分析

在AWS环境中实现自动化用户管理主要有三种路径：

1. SSM Run Command ：适合临时性操作但缺乏持久性
2. 自定义AMI ：用户数据固化在镜像中但灵活性差
3. 启动时脚本 ：通过UserData或.ebextensions实现动态配置

我们选择第三种方案，因其具有以下优势：

• 配置与实例解耦，更新无需重建AMI
• 可通过版本控制管理配置变更
• 支持动态参数注入（如不同环境使用不同用户集）

2.2 架构设计要点

完整的自动化流程包含三个关键环节：

1. 身份信息存储 ：将SSH公钥存储在AWS Systems Manager Parameter Store中
2. 配置注入 ：通过CloudFormation模板或EB环境变量传递用户名列表
3. 运行时执行 ：在实例启动时通过UserData脚本完成实际用户创建

# 示例：从Parameter Store获取密钥
aws ssm get-parameter --name "/myapp/ssh_keys/${username}" --with-decryption

3. 详细实现步骤

3.1 准备用户凭据

首先在Parameter Store中存储用户公钥（建议使用KMS加密）：

aws ssm put-parameter \
  --name "/myapp/ssh_keys/dev_user" \
  --value "ssh-rsa AAAAB3NzaC1..." \
  --type SecureString \
  --key-id alias/aws/ssm

3.2 创建.ebextensions配置

在项目根目录创建 .ebextensions/users.config 文件：

files:
  "/opt/scripts/add_users.sh":
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/bin/bash
      USERS=("dev_user" "ci_user")
      for USER in "${USERS[@]}"; do
        useradd -m -s /bin/bash $USER
        mkdir -p /home/$USER/.ssh
        aws ssm get-parameter --name "/myapp/ssh_keys/$USER" --with-decryption --query Parameter.Value --output text > /home/$USER/.ssh/authorized_keys
        chmod 600 /home/$USER/.ssh/authorized_keys
        chown -R $USER:$USER /home/$USER/.ssh
      done

commands:
  01_add_users:
    command: /opt/scripts/add_users.sh

3.3 高级权限配置

对于需要sudo权限的用户，可追加以下内容：

    content: |
      ...
      echo "$USER ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/$USER
      chmod 440 /etc/sudoers.d/$USER

4. 安全增强方案

4.1 最小权限原则

通过IAM策略限制Parameter Store访问权限：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter"
      ],
      "Resource": [
        "arn:aws:ssm:region:account-id:parameter/myapp/ssh_keys/*"
      ]
    }
  ]
}

4.2 审计日志记录

启用AWS CloudTrail记录所有Parameter Store访问：

aws cloudtrail put-event-selectors \
  --trail-name my-trail \
  --event-selectors '[{
      "ReadWriteType": "ReadOnly",
      "IncludeManagementEvents": true,
      "DataResources": [{
        "Type": "AWS::SSM::Parameter",
        "Values": ["arn:aws:ssm:region:account-id:parameter/myapp/ssh_keys/"]
      }]
  }]'

5. 实战问题排查

5.1 常见错误处理

问题1：脚本执行权限不足

• 现象：UserData执行但用户未创建
• 排查：检查 /var/log/cloud-init-output.log
• 解决：确保脚本有可执行权限（mode 755）

问题2：Parameter Store访问被拒

• 现象：IAM角色缺少ssm:GetParameter权限
• 测试：手动执行 aws ssm get-parameter 验证

5.2 调试技巧

1. 在实例启动时保留终止保护：

   aws ec2 modify-instance-attribute \
     --instance-id i-1234567890abcdef0 \
     --disable-api-termination
   

2. 查看完整的启动日志：

   cat /var/log/cloud-init.log
   cat /var/log/cloud-init-output.log
   

6. 方案优化方向

6.1 动态用户管理

结合Lambda实现用户生命周期管理：

import boto3

def handle_termination(event, context):
    ec2 = boto3.client('ec2')
    instance_id = event['detail']['instance-id']
    
    # 查询实例标签获取需要删除的用户
    tags = ec2.describe_tags(Filters=[{
        'Name': 'resource-id',
        'Values': [instance_id]
    }])
    
    # 执行用户删除操作...

6.2 多环境支持

通过EB环境变量区分开发/生产环境用户：

option_settings:
  aws:elasticbeanstalk:application:environment:
    USER_LIST: "dev_user,test_user"

然后在脚本中解析：

IFS=',' read -ra USERS <<< "$USER_LIST"

7. 替代方案比较

方案	优点	缺点	适用场景
UserData脚本	简单直接，无需额外服务	修改需重新部署	用户固定的简单环境
SSM State Manager	支持定期执行	需要额外配置	需要持续合规检查的环境
自定义IAM角色	与AWS服务深度集成	学习曲线陡峭	企业级身份联邦系统

在实际项目中，我推荐组合使用UserData和SSM：用UserData做初始配置，用SSM Maintenance Windows进行定期合规检查。这种混合方案既保证了启动速度，又能满足安全审计要求。

8. 关键安全注意事项

1. 密钥轮换策略 ：

   • 设置Parameter Store参数的过期时间
   • 使用AWS Secrets Manager自动轮换密钥

2. 实例元数据保护 ：

   # 限制IMDSv1访问
   aws ec2 modify-instance-metadata-options \
     --instance-id i-1234567890abcdef0 \
     --http-tokens required \
     --http-endpoint enabled
   

3. 用户活动监控 ：

   # 安装auditd并配置规则
   apt-get install auditd
   echo "-w /home -p wa -k home_dir" >> /etc/audit/rules.d/monitor.rules
   service auditd restart
   

9. 性能优化实践

当需要创建大量用户时（50+），原始方案可能遇到启动延迟问题。可通过以下方式优化：

1. 并行执行 ：

   parallel -j 10 <<EOF
   useradd user1
   useradd user2
   ...
   EOF
   

2. 预生成shadow文件 ：

   import crypt
   with open('/etc/shadow.preset', 'w') as f:
       f.write(f"user1:{crypt.crypt('temp_pwd')}:...")
   

3. 使用cloud-init模块 ：

   #cloud-config
   users:
     - name: dev_user
       ssh-authorized-keys: 
         - ssh-rsa AAAAB3Nza...
   

10. 企业级扩展方案

对于大型组织，建议采用以下架构：

1. 中央用户仓库 ：

   • 使用LDAP或Microsoft AD作为权威用户源
   • 通过SSSD连接EC2实例

2. 自动化流水线 ：

   graph LR
     A[HR系统] --> B[AD同步]
     B --> C[AWS IAM Identity Center]
     C --> D[EC2实例角色映射]
   

3. 合规检查 ：

   # 使用AWS Config规则检查用户配置
   aws configservice put-config-rule \
     --config-rule '{
       "ConfigRuleName": "ec2-user-check",
       "Source": {
         "Owner": "AWS",
         "SourceIdentifier": "INCOMING_SSH_DISABLED"
       }
     }'
   

在实际部署中，我发现结合AWS Organizations和SCP可以有效地跨账户管理EC2用户权限。例如，通过以下策略禁止直接创建本地管理员：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances"
      ],
      "Condition": {
        "StringLike": {
          "ec2:UserData": "*useradd*admin*"
        }
      },
      "Resource": "*"
    }
  ]
}

这种代码化的用户管理方式不仅提高了运维效率，更重要的是确保了环境的一致性。每次部署都是确定性的结果，彻底避免了"雪花服务器"问题。对于需要频繁扩展的EB环境，这已经成为我们团队的基础实践之一。