是否安全存储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存储桶<打击>使用 KMS 使用 S3服务器端加密 （<一href="http://stackoverflow.com/questions/30009184/ec2-instance-role-gets-unknown-error-when-attempting-aws-s3-cp-kms-encrypted-f">because在 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 creds被烤成的实例作为 ENV 瓦尔
• 上传和加密我的 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
  
  

在用户数据字段

In The User-Data Field

我输入以下到用户数据字段创建时，启动配置我希望我的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

以上执行以下操作：

The above does the following:

• 在更新软件包列表
• 在安装的Python（运行所需的 AWS-CLI ）
• 安装 AWS-CLI
• 更改为 /主页/ Ubuntu的用户目录
• 使用 AWS-CLI 从下载 Instance-Init.sh 文件S3 。由于 IAM角色分配给我的实例，我AWS creds会被自动地通过 AWS-CLI 发现。该 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 瓦尔脚本和泊坞窗运行，我需要部署在容器我实例。有点像这样：

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

非常方便

这创造了一个非常简便的方法，而无需创建一个新的启动配置更新用户数据剧本每次你需要做一个小的改动。而它确实让 ENV 瓦尔出你的codeBase的，进入一个狭窄的，可控的空间（ 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).

但是这一切都感觉有点不安全。把我的主DB creds到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. 有什么我在OPS我新生的日子很想念？
   
   

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?
   
   

感谢提前任何帮助。

推荐答案

你所描述什么是几乎正是我们使用的是从我们的注册表中实例化泊坞容器（我们现在使用V2自托管/私营，S3支持的泊坞窗-registry代替码头）投入生产。 FWIW，我有同样的这种感觉摇摇晃晃，你描述时，首先踩着这条道路的感觉，但将近一年，现在做这件事的经过 - 相比于存储这些敏感的配置数据在回购的替代或烤成图片 - 我相信它是处理这些数据的更好的方法之一。现在，他这样说，我们正在考虑使用 Hashicorp新Vault软件部署配置秘密取代这种共享加密秘密shell脚本容器（说五次快）。我们正在考虑的保管库的加密外包给开源社区（它所属）的相当，但配置存储。

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跳马），以取代我们的自产自销方法。祝你好运！

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屋！