> For the love of all that is good, save your .pem file to some kind of cloud storage so you’ll never be without it.
For the love of all that is good, don't do this for anything beyond random hobbyist screwing around. A Dropbox compromise shouldn't risk your entire company's server infrastructure.
> If you only have need for one free tier instance leave it running.
No, because the 750 hours/month can be used by more than one instance. You could, for example, try out database clustering by running two t1.micro instances for two weeks.
> Finally resist the urge to use your GUI when working with your project even when your working with your project on a local machine you’ll find that as you move along with your project you’ll be in better control of the project when it’s on the remote server.
The AWS Console is perfectly usable for 99% of what you'll need to do. Most users won't need anything beyond it.
> For the love of all that is good, don't do this ...
I, too, was astounded that anybody would be recommending keeping your keys 'public' like this. By all means, keep it on a few USB sticks that are nicely secure - and have a good plan in place in case you lose one.
By all means, have a separate, passphrase-protected key for each separate device (desktop, laptop, tablet) and push them to your machines using something like chef and the 'users' and 'sudo' community cookbooks, at a minimum, and destroy the .pem after you initially set up the host.
There is a reason that Amazon only configures one user with only one key, and it's not because that's how sane people access their machine.
A few things you can do back up your private key safely (correct me if I'm wrong here.)
- Encrypt the pem file with a gpg passphrase you can memorize or put in a password manager
or
- Create a new IAM AWS account with a strong password, turn on 2-factor authentication, and grant access to the keys bucket for just that account. Make sure you turn on S3-side AES256 bit at-rest encryption for the file.
The latter still has the risk of a complete AWS breach and S3 encryption key compromise, or someone hacking into your admin account somehow (in which case you have bigger problems), but that seems much less likely than say someone just snagging your laptop and getting the key off of it.
In practice I have a single jump node in a VPC facing the internet in a security group with my IP whitelisted that has 2-factor authentication with a PAM module for google authenticator and a strong password, so they would need my phone, the password, my IP, and the backend nodes' private key to get to any machine.
If you keep one key per device, you can revoke it if/when that device is compromised, stolen, etc..
That key is for initial access to provision your machine, after which you should have a more sophisticated means of managing users, as certainly, if you are doing anything of much importance, you will eventually need at least 2.
If that's the case, it's kinda pointless advice - none of the commonly used Linux AMIs have GUIs installed, and someone who can install X on one probably knows the CLI already.
If you choose to upload .pem to cloud storage, make sure you secure (encrypt) your .pem file, since it allows total access to the boxes! You should also secure remote access via the "security groups" firewall by only allowing known ip addresses (you can edit this via the aws console as needed). Since he mentioned the "The Command Line Crash Course" [1]. I might chime in with a couple into screencasts I've created.
I email myself my encryption passwords so that I - and any interested government agencies - can log in without me needing to remember them all the time.
Once you have physical access, no need for the private key. Unless you're encrypting all of your data, they'll just snapshot your VM to go through it later (or your EBS volume, depending on where the data is stored).
And yes, you can write out whatever is in RAM just as easily.
Did everyone forget that "cloud" means "someone else fully controls the hardware"?
I was replying to this parent post: "I email myself my encryption passwords so that I - and any interested government agencies - can log in without me needing to remember them all the time."
Yes, you should protect your private key. No, protecting it isn't going to stop a government agency. A VM is not Schroeder's cat: you can peak without there being any evidence. That was my point. Apologies if I wasn't straightforward in my explanation.
It's actually kind of hard to remember sometimes that cloud-compute providers don't employ some sort of homeomorphically-encrypted VM containers. Even though they are completely impractical and have never even seen a proof-of-concept, the idea is so intuitive that I bet if you asked a random non-IT manager if Amazon could read memory or CPU registers on the instances his employees have running on EC2, he'd say no. "Because obviously," he'd pontificate, "nobody would be using cloud-computation otherwise."
If I want my data to be very secure, its going to run on VMs that boot and run entirely in RAM, read the encrypted data in from persistent storage, and have their power controlled by an intrusion detection system. If you attempt to open the rack, power is removed, unencrypted data is lost, and everything is safely encrypted at rest.
You would only need this security for the most sensitive types of data though.
A bit disappointed by this. As mentioned by ceejayoz, don't upload your .pem file anywhere!
AWS has tons of weird/interesting quirks - I thought this article was going to be about those.
Here's my 5 tips for AWS...
- SQS: encodes messages by default! plan accordingly if you are going to be sending large bodies (265K max).
- ELBs: they need time to warm up if you get a huge traffic spike. ELBs won't start scaling unless that traffic is sustained for a certain time (usually minutes).
- S3: watch out for "eventual consistency" if you're going to upload lots of files and try to access them right away - they might not be available immediately.
- Cloudwatch: set up alarms to make sure your billing never goes over threshold X in time Y. If someone compromised your account (because you uploaded your .pem file in cleartext to dropbox) and is mining bitcoins on your machines, you'll be notified.
- VPC: if you're going to build a services-oriented infrastructure, consider using a VPC! Unless you need to have all your services exposed to the public internet, it could save you a lot of time and security configuration trouble.
On the last point, just use a VPC, period. I believe Amazon has now made this the default for new accounts, in fact. They come with no downsides and lots of benefits - being able to change security groups on the fly, elastic IPs that stay with the instance when stopped, etc.
I really apologize for wasting your time perhaps I will post these as a question next time. In any case I sincerely appreciate the feedback and your additional tips.
> - S3: watch out for "eventual consistency" if you're going to upload lots of files and try to access them right away - they might not be available immediately.
This is only true in the "US Standard" region. Other regions get read-after-write consistency (but not read-after-update, read-after-delete, etc). "US Standard" is the only bi-coastal S3 region, so I guess that consistency level would be too expensive, latency-wise.
My tip number 0: Use a CMS. It's a beautiful thing to start an ec2 instance, run Ansible, get a drink of water, and return to a fully provisioned and configured machine.
Tip 0.1: Use Vagrant with an EC2 box, and just 'vagrant up' yourself a fully operational machine.
Why are people so thrilled about a slower more error prone way to do what amazon provides already? Just make an ami for each kind of server you want. Now you skip the waiting part, and the "oops, my pile of messy ruby scripts fucked up configuring the server" parts.
You can use Ansible to create an AMI to get the best of both worlds - fast provisioning, plus the ability to make new AMIs in a repeatable, self-documenting manner. You're arguing configuration management is "error prone", but I've found it a lot less error prone than other methods. If something doesn't install right I can blow away the whole thing rather than trying to un-break a destroyed install.
If your Ansible scripts are in Ruby you've done something very odd, and if they're messy it's your own fault. Mine are pretty clean, and once built they work the same way for subsequent runs.
Seriously? Read the thread. You responded to "Using config tools isn't helpful" with "but mine is python!!1". Nobody cares, it is a completely irrelevant detail. I simply said ruby because the two popular options are both ruby. It still applies to fucking cfengine, it doesn't matter the specific tool.
The Ruby-based CMSes are very, very different from tools like Ansible. That's an important issue when you're bashing the entire range, seemingly without any thought for the situations that make them useful and without knowledge of other options than Puppet/Chef.
>The Ruby-based CMSes are very, very different from tools like Ansible
No they are not. I've probably been doing system administration longer than you have been alive. I've used everything from cfengine to salt. They all cause more problems than they solve.
How do you create that initial AMI? CMs make answering that question simple.
AMIs are nice - but they're merely snapshots of an end product. Being able to get to that end product in a repeatable, idempotant and self-documenting fashion is just as nice.
So is being able to create a virtual image on your own machine with the same end product.
FWIW, Vagrant lets you specify an AMI in its box description, so you get the best of both of your worlds there.
>How do you create that initial AMI? CMs make answering that question simple.
No, they make it slower and more complex. The idea being that after you have built a config, future clones will be easier. But you already get a better solution just setting up a server and then making an AMI from it. Cfengine and friends offer quite literally zero benefits for this sort of scenario.
You missed two points. How did you create that first image? Exactly what versions of packages, packages, configurations, etc were installed? Being unable to answer that question will hurt you more in the long run than you might expect.
Second, if you should move from AWS to (as an example of a second popular PAAS provider) Rackspace, how do you recreate that image? If you want to create a local VM to perform development on, how do you do that?
Now, if I were limited to just using one CMS, I might agree with you. There are some really obtuse ones out there that require a lot of learning. I don't think Ansible falls into this category. You're not writing python, you're not writing in some tool specific DSL, you're writing lists of packages, to be installed in-order. Simple and straightforward.
I didn't miss any points. Every package manager can accept a list of packages. You missed learning the most basic fundamentals of your OS. And once again, the specific tool does not matter. They all do the same thing, and they all do it in an error prone and ill-conceived way. Hell, nix is a better "CM" tool than the real ones, and it is just a package manager.
Don't listen to these comments. I urge EVERYONE to save their perm files somewhere. Trust me, the rist of getting compromised is nothing compared to the risk you're exposing yourself to if you don't.
55 comments
[ 3.2 ms ] story [ 119 ms ] threadFor the love of all that is good, don't do this for anything beyond random hobbyist screwing around. A Dropbox compromise shouldn't risk your entire company's server infrastructure.
> If you only have need for one free tier instance leave it running.
No, because the 750 hours/month can be used by more than one instance. You could, for example, try out database clustering by running two t1.micro instances for two weeks.
> Finally resist the urge to use your GUI when working with your project even when your working with your project on a local machine you’ll find that as you move along with your project you’ll be in better control of the project when it’s on the remote server.
The AWS Console is perfectly usable for 99% of what you'll need to do. Most users won't need anything beyond it.
I, too, was astounded that anybody would be recommending keeping your keys 'public' like this. By all means, keep it on a few USB sticks that are nicely secure - and have a good plan in place in case you lose one.
There is a reason that Amazon only configures one user with only one key, and it's not because that's how sane people access their machine.
- Encrypt the pem file with a gpg passphrase you can memorize or put in a password manager
or
- Create a new IAM AWS account with a strong password, turn on 2-factor authentication, and grant access to the keys bucket for just that account. Make sure you turn on S3-side AES256 bit at-rest encryption for the file.
The latter still has the risk of a complete AWS breach and S3 encryption key compromise, or someone hacking into your admin account somehow (in which case you have bigger problems), but that seems much less likely than say someone just snagging your laptop and getting the key off of it.
In practice I have a single jump node in a VPC facing the internet in a security group with my IP whitelisted that has 2-factor authentication with a PAM module for google authenticator and a strong password, so they would need my phone, the password, my IP, and the backend nodes' private key to get to any machine.
That key is for initial access to provision your machine, after which you should have a more sophisticated means of managing users, as certainly, if you are doing anything of much importance, you will eventually need at least 2.
I believe the author was referring to navigating the filesystem and running commands via CLI (e.g. `cd` and `ls`, not `ec2-describe-instances`).
Crash Course on the Filesystem Hierarchy Standard @ http://sysadmincasts.com/episodes/12-crash-course-on-the-fil...
Crash Course on Common Commands @ http://sysadmincasts.com/episodes/13-crash-course-on-common-...
Crash Course on Man Pages @ http://sysadmincasts.com/episodes/19-crash-course-on-man-pag...
[1] http://cli.learncodethehardway.org/book/
Edit: Please don't just downvote when I rebut sarcasm/snark with fact. Discuss!
And yes, you can write out whatever is in RAM just as easily.
Did everyone forget that "cloud" means "someone else fully controls the hardware"?
That the most sophisticated attacker with the most resources may be able to tunnel into your data is no excuse for lax security.
Yes, you should protect your private key. No, protecting it isn't going to stop a government agency. A VM is not Schroeder's cat: you can peak without there being any evidence. That was my point. Apologies if I wasn't straightforward in my explanation.
If I want my data to be very secure, its going to run on VMs that boot and run entirely in RAM, read the encrypted data in from persistent storage, and have their power controlled by an intrusion detection system. If you attempt to open the rack, power is removed, unencrypted data is lost, and everything is safely encrypted at rest.
You would only need this security for the most sensitive types of data though.
AWS has tons of weird/interesting quirks - I thought this article was going to be about those.
Here's my 5 tips for AWS...
- SQS: encodes messages by default! plan accordingly if you are going to be sending large bodies (265K max).
- ELBs: they need time to warm up if you get a huge traffic spike. ELBs won't start scaling unless that traffic is sustained for a certain time (usually minutes).
- S3: watch out for "eventual consistency" if you're going to upload lots of files and try to access them right away - they might not be available immediately.
- Cloudwatch: set up alarms to make sure your billing never goes over threshold X in time Y. If someone compromised your account (because you uploaded your .pem file in cleartext to dropbox) and is mining bitcoins on your machines, you'll be notified.
- VPC: if you're going to build a services-oriented infrastructure, consider using a VPC! Unless you need to have all your services exposed to the public internet, it could save you a lot of time and security configuration trouble.
This is only true in the "US Standard" region. Other regions get read-after-write consistency (but not read-after-update, read-after-delete, etc). "US Standard" is the only bi-coastal S3 region, so I guess that consistency level would be too expensive, latency-wise.
Tip 0.1: Use Vagrant with an EC2 box, and just 'vagrant up' yourself a fully operational machine.
If your Ansible scripts are in Ruby you've done something very odd, and if they're messy it's your own fault. Mine are pretty clean, and once built they work the same way for subsequent runs.
The popular options are in ruby. Just because you use a less popular one that is written in python doesn't change the main point.
If you're intending to bash Puppet/Chef, why are you doing it in response to someone mentioning how handy Ansible is?
No they are not. I've probably been doing system administration longer than you have been alive. I've used everything from cfengine to salt. They all cause more problems than they solve.
AMIs are nice - but they're merely snapshots of an end product. Being able to get to that end product in a repeatable, idempotant and self-documenting fashion is just as nice.
So is being able to create a virtual image on your own machine with the same end product.
FWIW, Vagrant lets you specify an AMI in its box description, so you get the best of both of your worlds there.
No, they make it slower and more complex. The idea being that after you have built a config, future clones will be easier. But you already get a better solution just setting up a server and then making an AMI from it. Cfengine and friends offer quite literally zero benefits for this sort of scenario.
Second, if you should move from AWS to (as an example of a second popular PAAS provider) Rackspace, how do you recreate that image? If you want to create a local VM to perform development on, how do you do that?
Now, if I were limited to just using one CMS, I might agree with you. There are some really obtuse ones out there that require a lot of learning. I don't think Ansible falls into this category. You're not writing python, you're not writing in some tool specific DSL, you're writing lists of packages, to be installed in-order. Simple and straightforward.
Versus2nd, know your usage upfront before you incur thousands of dollars in usage fees! services like dynamoDB can become very expensive very fast!