bash - Is it secure to store EC2 User-Data shell scripts in a private S3 bucket? -


i have ec2 asg on aws , i'm interested in storing shell script that's used instantiate given instance in s3 bucket , have downloaded , run upon instantiation, feels little rickety though i'm using iam instance role, transferring via https, , encrypting script while @ rest in s3 bucket using kms using s3 server side encryption (because kms method throwing 'unknown' error).

the setup

in user-data field

i input following user data field when creating launch configuration want asg 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 following:

  • updates package lists
  • installs python (required run aws-cli)
  • installs aws-cli
  • changes /home/ubuntu user directory
  • uses aws-cli download instance-init.sh file s3. due iam role assigned instance, aws creds automagically discovered aws-cli. iam role grants instance permissions necessary decrypt file.
  • makes executable
  • runs script
  • deletes script after it's completed.

the instance-init.sh script

the script stuff setting env vars , docker run containers need deployed on instance. kinda 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 


very handy

this creates handy way update user-data scripts without need create new launch config every time need make minor change. , great job of getting env vars out of codebase , narrow, controllable space (the instance-init.sh script itself).

but feels little insecure. idea of putting master db creds file on s3 unsettling least.

the questions

  1. is common practice or dreaming bad idea here?
  2. does fact file downloaded , stored (albeit briefly) on fresh instance constitute vulnerability @ all?
  3. is there better method deleting file in more secure way?
  4. does matter whether file deleted after it's run? considering secrets being transferred env vars seems redundant delete instance-init.sh file.
  5. is there i'm missing in nascent days of ops?

thanks in advance.

what describing using instantiate docker containers our registry (we use v2 self-hosted/private, s3-backed docker-registry instead of quay) production. fwiw, had same "this feels rickety" feeling describe when first treading path, after year of doing -- , compared alternative of storing sensitive configuration data in repo or baked image -- i'm confident it's 1 of better ways of handling data. now, being said, looking @ using hashicorp's new vault software deploying configuration secrets replace "shared" encrypted secret shell script container (say 5 times fast). thinking vault equivalent of outsourcing crypto open source community (where belongs), configuration storage.

in fewer words, haven't run across many problems similar situation we've been using year, looking @ using external open source project (hashicorp's vault) replace our homegrown method. luck!


Comments

Popular posts from this blog

python - Mongodb How to add addtional information when aggregating? -

java - Spring Data JPA: Why findOne(id) executing delete query internally? -

java - Incorrect order of records in M-M relationship in hibernate -