I thought I'd share some of the awesome features we've baked into Active Local with you. While we designed the site to make it easy to browse through activities happening in your area, we've also made it easy for you to contribute activities too. I put a little screencast together showing how to do this:
Amazon AWS is awesome. It makes it stupidly simple to create and deploy complex, load balanced applications with servers in multiple locations around the country (EC2 and ELB), redundant database servers with failover (RDS), unlimited storage guaranteed for at least 10 million years (S3)... the list goes on. But one thing that wasn't so easy, until recently, was security. How do you give your developers and servers access to only the parts of AWS that they needed? That's where Identity and Access Management (IAM) comes in.
With IAM you can create users and policies which define what products (technically, what API calls) a user is allowed to make. With Active Trainer 2.0, for example, all the developers have full access to our AWS account, but the application servers only have access to get and put objects into S3. This way if one of the servers was ever compromised and the attacker got ahold of the access key and secret key (which Amazon requires to make API calls), the worst damage they could do would be to put a bunch of objects into our S3 bucket. Not the end of the world.
Setting up IAM is relatively easy. Amazon doesn't have a GUI for using IAM just yet, so you have to use command line tools. You can get those here:
First we're going to create a group for our admins. We'll put the access rules on the group itself so that any new users we put into this group automatically inherit those permissions. To create a group:
iam-groupcreate -g admins
Now we'll create a user and put them into our new group:
iam-usercreate -u johndoe -g admins -k -v
This command will return that user's new access key and secret key. Write these down and give them to the new user when they're ready to start using the tools.
So we've got a new user but by default IAM enforces a "deny all" policy, so they can't do anything yet. Now we'll give the admins group a policy. Policies can be a little confusing at first and to help you generate them Amazon has put together a neat utility called the AWS Policy Generator. You can learn more about this on the site, but for this blog post I'm going to give you a couple policies to get started.
Admins will be allowed to do anything, and the policy that defines that looks like this:
In this case we gave the policy a name of "admins_group_policy." You can set this to whatever you want.
So now our 'johndoe' user can make API calls to Amazon. And if, one day, johndoe leaves the company, you simply remove his user from the admins group and all of his access goes away. You can read more about this in the IAM docs.
Here's a policy that we use on our application servers:
This policy only allows calls to the given API methods (listed under "Action") and only allows them to be called on the listed buckets and objects (listed under "Resource"). You can get even more fine-grained than this and do stuff like only allowing access to a single API call from a given IP address during certain times of the day. Policies are really powerful.
IAM is awesome. It gives you some great security controls on your AWS services and keeps things safe for users and applications that need to use those services. If you're not using it already, what are you waiting for?