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 using kmss3 server side encryption (because kms method throwing 'unknown' error).
the setup
- created
iam instance rolegets assigned instance in asg upon instantiation, resulting in aws creds being baked instanceenvvars - uploaded , encrypted
instance-init.shscript s3 resulting in private endpoint : https://s3.amazonaws.com/super-secret-bucket/instance-init.sh
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/ubuntuuser directory - uses
aws-clidownloadinstance-init.shfiles3. dueiam roleassigned instance, aws creds automagically discoveredaws-cli.iam rolegrants 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
- is common practice or dreaming bad idea here?
- does fact file downloaded , stored (albeit briefly) on fresh instance constitute vulnerability @ all?
- is there better method deleting file in more secure way?
- does matter whether file deleted after it's run? considering secrets being transferred
envvars seems redundant deleteinstance-init.shfile. - 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
Post a Comment