公司一般会采取内网+域账号+动态口令+跳板机的方式来保证生产环境的安全。这套机制确实好用,但是也有一些问题,比如需要单独的服务器,耗费资源;大家共用跳板机,使得跳板机可能成为瓶颈。在云计算时代,跳板机不能很好地满足公有云环境的安全了。
针对传统跳板机的问题,AWS推出了EC2 Systems Manager
。EC2 Systems Manager
不需要单独的机器,拥有完善的IAM控制,还可以通过CloudTrail收集操作信息,优点很多。
这篇文站:使用Amazon EC2 Systems Manager取代堡垒机详细介绍了EC2 Systems Manager
的优势,并且给出了体验的方法。下面就根据这篇文章体验一下EC2 Systems Manager
功能。
- 通过文章里面给出的CloudFormation创建好相关的资源。
- 进入EC2控制,侧边栏选择
托管实例
,然后点击上面的运行命令
按钮。
- 接着选择
AWS-RunShellScript
- 我们执行一下
uname -a
命令。设置好SNS需要的配置,这样执行完命令之后会有通知。如果要将命令执行结果保存到S3里面,也可以设置上S3 bucket。CloudFormation
已经创建好了一个名为ssm-output-history-${account_id}-us-east-1
的S3 bucket。
- 执行完命令之后,可以查看一下命令具体的执行结果。
- SNS也把命令的执行结果发到邮箱里了。
EC2 Systems Manager
不需要独立的机器,需要在执行命令的机器上安装SSM Agent
。登录到EC2,可以发现这个agent进程。
SSM Agent
通过IAM角色与Systems Manager
进行通信。这个角色必须具有足够权限与Systems Manager
及其辅助服务进行交互。IAM已经提供了一个名为AmazonEC2RoleforSSM的托管策略,为您预先定义了这些权限:允许代理程序获取并回复Systems Manager
消息、发布CloudWatch
指标、并将日志文件写入S3
。
授予Systems Manager
策略的角色使用的是EC2的附加角色功能。
命令运行完成之后,可以去OSS里面看日志。但是我在OSS里面并没有发现相关的日志,于是去配置好CloudTrail
和CloudWatch
排查问题。通过CloudTrail
收集OSS的操作信息,通过CloudWatch
分析数据。
发现是权限出了问题,于是去S3 bucket里面把存储桶策略
里面的policy删除掉了,然后就可以在这个bucket里面看到日志了。具体原因要分析一下这个policy。
网友评论