将 EC2 用户数据 shell 脚本存储在私有 S3 存储桶中是否安全? [英] Is it secure to store EC2 User-Data shell scripts in a private S3 bucket?

问题描述

我在 AWS 上有一个 EC2 ASG，我有兴趣存储用于在 S3 存储桶中实例化任何给定实例的 shell 脚本，并下载它并在实例化时运行，但尽管我感觉有点摇摇欲坠'正在使用 IAM 实例角色，通过 HTTPS 传输，并在 S3 存储桶中静止时加密脚本本身 using KMS using S3 服务器端加密 (因为KMS 方法抛出未知"错误).

I have an EC2 ASG on AWS and I'm interested in storing the shell script that's used to instantiate any given instance in an S3 bucket and have it downloaded and run upon instantiation, but it all feels a little rickety even though I'm using an IAM Instance Role, transferring via HTTPS, and encrypting the script itself while at rest in the S3 bucket using KMS using S3 Server Side Encryption (because the KMS method was throwing an 'Unknown' error).

设置

• 创建了一个 IAM 实例角色，该角色在实例化时分配给我的 ASG 中的任何实例，导致我的 AWS 凭证作为 ENV vars 被烘焙到实例中
• 将我的 Instance-Init.sh 脚本上传并加密到 S3，从而产生一个私有端点，如下所示:https://s3.amazonaws.com/super-secret-bucket/Instance-Init.sh
  
  

• Created an IAM Instance Role that gets assigned to any instance in my ASG upon instantiation, resulting in my AWS creds being baked into the instance as ENV vars
• Uploaded and encrypted my Instance-Init.sh script to S3 resulting in a private endpoint like so : https://s3.amazonaws.com/super-secret-bucket/Instance-Init.sh
  
  

在 User-Data 字段

In The User-Data Field

我在创建 Launch Configuration 时将以下内容输入到 User Data 字段中，我希望我的 ASG 使用:

I input the following into the User Data field when creating the Launch Configuration I want my ASG to use:

#!/bin/bash

apt-get update
apt-get -y install python-pip
apt-get -y install awscli
cd /home/ubuntu
aws s3 cp s3://super-secret-bucket/Instance-Init.sh . --region us-east-1
chmod +x Instance-Init.sh
. Instance-Init.sh
shred -u -z -n 27 Instance-Init.sh

上面做了以下事情:

• 更新包列表
• 安装 Python(需要运行 aws-cli)
• 安装 aws-cli
• 更改为 /home/ubuntu 用户目录
• 使用 aws-cli 从 S3 下载 Instance-Init.sh 文件.由于分配给我的实例的 IAM 角色，aws-cli 会自动发现我的 AWS 凭证.IAM 角色 还授予我的实例解密文件所需的权限.
• 使其可执行
• 运行脚本
• 完成后删除脚本.
  
  

• Updates package lists
• Installs Python (required to run aws-cli)
• Installs aws-cli
• Changes to the /home/ubuntu user directory
• Uses the aws-cli to download the Instance-Init.sh file from S3. Due to the IAM Role assigned to my instance, my AWS creds are automagically discovered by aws-cli. The IAM Role also grants my instance the permissions necessary to decrypt the file.
• Makes it executable
• Runs the script
• Deletes the script after it's completed.
  
  

Instance-Init.sh 脚本

The Instance-Init.sh Script

脚本本身会做一些事情，比如设置env vars 和docker run 我需要在我的实例上部署的容器.有点像这样:

The script itself will do stuff like setting env vars and docker run the containers that I need deployed on my instance. Kinda like so:

#!/bin/bash

export MONGO_USER='MyMongoUserName'
export MONGO_PASS='Top-Secret-Dont-Tell-Anyone'

docker login -u <username> -p <password> -e <email>
docker run - e MONGO_USER=${MONGO_USER} -e MONGO_PASS=${MONGO_PASS} --name MyContainerName quay.io/myQuayNameSpace/MyAppName:latest

非常方便

这创建了一种非常方便的方法来更新 User-Data 脚本，而无需在每次需要进行细微更改时创建新的 Launch Config.它在将 env 变量从您的代码库中取出并放入一个狭窄、可控的空间(Instance-Init.sh 脚本本身)方面做得非常出色.

This creates a very handy way to update User-Data scripts without the need to create a new Launch Config every time you need to make a minor change. And it does a great job of getting env vars out of your codebase and into a narrow, controllable space (the Instance-Init.sh script itself).

但这一切都让人觉得有点不安全.将我的主数据库凭证放入 S3 上的文件的想法至少可以说令人不安.

But it all feels a little insecure. The idea of putting my master DB creds into a file on S3 is unsettling to say the least.

问题

1. 这是一种常见的做法还是我在这里幻想了一个坏主意?
2. 文件在新实例上下载和存储(尽管是短暂的)这一事实是否构成漏洞?
3. 是否有更好的方法以更安全的方式删除文件?
4. 文件在运行后是否被删除有关系吗?考虑到机密正在传输到 env 变量，删除 Instance-Init.sh 文件似乎是多余的.
5. 在我刚开始运营的日子里，有什么我遗漏的吗?
   
   

1. Is this a common practice or am I dreaming up a bad idea here?
2. Does the fact that the file is downloaded and stored (albeit briefly) on the fresh instance constitute a vulnerability at all?
3. Is there a better method for deleting the file in a more secure way?
4. Does it even matter whether the file is deleted after it's run? Considering the secrets are being transferred to env vars it almost seems redundant to delete the Instance-Init.sh file.
5. Is there something that I'm missing in my nascent days of ops?
   
   

提前感谢您的帮助.

推荐答案

您所描述的几乎正是我们用来从注册表实例化 Docker 容器的内容(我们现在使用 v2 自托管/私有、s3 支持的 docker-registry 而不是 Quay)投入生产.FWIW，当你第一次踏上这条路时，我有同样的这感觉摇摇欲坠"的感觉，但经过近一年的努力——与将这些敏感的配置数据存储在回购或烘焙到的替代方案相比图像——我相信这是处理这些数据的更好方法之一.现在，话虽如此，我们目前正在考虑使用 Hashicorp 的新 Vault 软件 将配置机密部署到替换这个共享"加密的秘密 shell 脚本容器(比方说快五倍).我们认为 Vault 将相当于将加密外包给开源社区(它所属的地方)，但用于配置存储.

What you are describing is almost exactly what we are using to instantiate Docker containers from our registry (we now use v2 self-hosted/private, s3-backed docker-registry instead of Quay) into production. FWIW, I had the same "this feels rickety" feeling that you describe when first treading this path, but after almost a year now of doing it -- and compared to the alternative of storing this sensitive configuration data in a repo or baked into the image -- I'm confident it's one of the better ways of handling this data. Now, that being said, we are currently looking at using Hashicorp's new Vault software for deploying configuration secrets to replace this "shared" encrypted secret shell script container (say that five times fast). We are thinking that Vault will be the equivalent of outsourcing crypto to the open source community (where it belongs), but for configuration storage.

简而言之，我们使用了大约一年的时间并没有遇到很多与非常相似的情况的问题，但我们现在正在考虑使用外部开源项目(Hashicorp 的 Vault)来取代我们自己开发的方法.祝你好运！

In fewer words, we haven't run across many problems with a very similar situation we've been using for about a year, but we are now looking at using an external open source project (Hashicorp's Vault) to replace our homegrown method. Good luck!

这篇关于将 EC2 用户数据 shell 脚本存储在私有 S3 存储桶中是否安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！