There is a question that asks How to opt-in for AWS EC2 AMI from SDK?. And as I understand, it's not possible to do it. But is it possible to at least understand if AMI requires Opt-In? And if our account already opted in or not? (via SDK, programmatically)
The problem I'm trying to solve is some application for end-user where the user provides their own credentials, and the application instantiates an instance of some AMI. Currently, if the user does not have EULA accepted yet, the operation will fail. And all we can do is pick the license link, ask the user to accept it and then retry what he did. This doesn't really seem to be user friendly though. So, I thought there might be a way to know that in advance. Is there any?
Related
Im hoping to move an application to AWS.
I would like to use the AutoScaling so not all my EC2 instances are in use when the application use is quiet.
My problem is.....
I have one service account used for all communication between the various components of the application and the servers in that environment
We have a security exception with my company which allows us to use the service account to perform its actions on each individual server.
Every time we introduce a new server to the environment, we have to request that the security team update our exception list to allow the new server in as well.
There is no automatic method for doing this. We have to submit a request to the security team asking for the new server to be added to the exception.
So while AutoScaling would be prefect how can it work in this case if each time a server is added the security team needs to be notified so they can add the new server to the exception list?
Thanks
You can get notifications when your autoscale group scales either up or down. SNS can send a variety of things, including SMS (text) messages to a cell phone.
While this would work, it is incredibly manual. The goal of an autoscale group is to let the environment expand and contract without human intervention. I personally would not implement this as, depending on the availability of your security team they may be a bottle neck to scaling up. If for some reason they miss the scale up event that signals them to do something then you've got orphan machines that you're paying for that are doing nothing.
Additionally, there are also ways to script the provisioning of a new machine. Perhaps there is a way to add what you want automatically. AWS calls this userdata - you can learn a bit more about it from the AWS EC2 docs.
But ultimately I'd really take a step back and look at your architecture. If you can't script the machine provisioning then autoscaling is not very worthwhile - it's just plain "have devops add another machine if needed and hope they remember to take it down when it's not needed".
They don't want to give me their Amazon username and password because it has their complete purchase history.
Is there anyway for them to authorize me as a user?
Amazon has AWS Identity and Access Management, that should help with what your asking. http://aws.amazon.com/iam/
It's easy enough to create new accounts on Amazon, and it's also reasonable to keep corporate and personal accounts separate for expense purposes. I'd recommend doing that for simplicity, but I understand that it could be a concern regarding potential misuse on the rest of the Amazon site.
The use of access keys (as suggested by #KristianGlass) may be adequate, as well, allowing you to create and kill instances, but not allowing you access to the main AWS console. Elasticfox also works with the EC2 keys, so you could use that as a surrogate for the console.
Depending on what you're looking for, they might just be able to create you an Access Key and have you use that.
If they look under "Security Credentials" in their Account page (this should be a link to it) they can easily "Create a new Access Key" (they will of course need to give you both the Access Key ID and the Secret Access Key).
To paraphrase Amazon's documentation about Access Keys, you can use them for making requests to REST or Query APIs - specifically this includes EC2.
I have just installed a fedora linux AMI on amazon EC2, from the amazon collection. I plan to connect it to EBS storage. Assuming I have done nothing more than the most basic steps, no password changed, nothing extra has been done at this stage other than the above.
Now, from this point, what steps should I take to stop the hackers and secure my instance/EBS?
Actually there is nothing different here from securing any other Linux server.
At some point you need to create your own image (AMI). The reason for doing this is that the changes you will make in an existing AMI will be lost if your instance goes down (which could easily happen as Amazon doesn't guarantee that an instance will stay active indefinitely). Even if you do use EBS for data storage, you will need to do the same mundane tasks configuring the OS every time the instance goes down. You may also want to stop and restart your instance in certain periods or in case of peak traffic start more than one of them.
You can read some instructions for creating your image in the documentation. Regarding security you need to be careful not to expose your certification files and keys. If you fail on doing this, then a cracker could use them to start new instances that will be charged for. Thankfully the process is very safe and you should only pay attention in a couple of points:
Start from an image you trust. Users are allowed to create public images to be used by everyone and they could either by mistake or in purpose have left a security hole in them that could allow someone to steal your identifiers. Starting from an official Amazon AMI, even if it lacks some of the features you require, is always a wise solution.
In the process of creating an image, you will need to upload your certificates in a running instance. Upload them in a location that isn't bundled in the image (/mnt or /tmp). Leaving them in the image is insecure, since you may need to share your image in the future. Even if you are never planning to do so, a cracker could exploit a security fault in the software your using (OS, web server, framework) to gain access in your running instance and steal your credentials.
If you are planning to create a public image, make sure that you leave no trace of your keys/identifies in it (in the command history of the shell for example).
What we did at work is we made sure that servers could be accessed only with a private key, no passwords. We also disabled ping so that anyone out there pinging for servers would be less likely to find ours. Additionally, we blocked port 22 from anything outside our network IP, wit the exception of a few IT personnel who might need access from home on the weekends. All other non-essential ports were blocked.
If you have more than one EC2 instance, I would recommend finding a way to ensure that intercommunication between servers is secure. For instance, you don't want server B to get hacked too just because server A was compromised. There may be a way to block SSH access from one server to another, but I have not personally done this.
What makes securing an EC2 instance more challenging than an in-house server is the lack of your corporate firewall. Instead, you rely solely on the tools Amazon provides you. When our servers were in-house, some weren't even exposed to the Internet and were only accessible within the network because the server just didn't have a public IP address.
The ec2-describe-instances command is not very helpful in distinguishing the instances.
Are there command line tools that give a better overview?
Perhaps somewhat like http://github.com/newbamboo/manec2 but with support for different regions etc.
Amazon recently has added a feature to 'tag' your EC2 instances.
You can use security group to identify your instance. See http://www.shlomoswidler.com/2009/06/tagging-ec2-instances-using-security_30.html
You can add an empty security_group to each instance to be able to communicate with each other.
I'm using http://github.com/cocoy/mr.awsome to provision and name instance via security groups. This way I can identify each instance whether I'm using Elasticfox, AWS console, or the same tool mr.awsome.
See also: http://www.capsunlock.net/2010/05/five-easy-steps-to-tag-ec2-instance-using-mr-awsome.html
Cheers,
Rodney
http://www.capunlock.net
I think Rodney's method of using securty groups is the most comprehensive, but if you just want a way to assign a free-form tag to your instances, you can do that if you set up a free account at RightScale and use it to launch your instances. Warning - you'll have to put up with occasional emails from RightScale asking if you want to use their paid services.
This isn't a command-line solution, and it's far from perfect, but my company currently maintains a shared Word document in a Dropbox folder that maintains the role/name -> instance id mapping for all of our active instances.
Using a Word document also allows us to keep track of some more information that is nice to have available at a glance:
The "environment" the instance is a part of.
The RDP shortcut to the instance for simple access.
The AMI the instance was launched from.
Any additional attached volumes.
The region the instance is in.
etc.
I know there are tools to manage your EC2 environment. I currently use the Eclipse Plugin and the iPhone app iAWSManager. What i'm looking for is a management service that allows you to create multiple users with roles and privileges. I have clients that sign up for EC2 but need help setting up and managing everything. At the very least they should be able to setup multiple logins so they can monitor who is doing what on the account (rather than sharing the single login). Better would be to assign privileges for who could create and launch an instance, create and assign/just assign Elastic IPs/EBS to instances etc.
Since enterprises are supposed to be using EC2 how do they manage this well? How do they create audit trails of activity?
RightScale, YLastic or EnStratus support roles and priviledges. However, they are not for free...
I'll add Scalr to the list, which is a cloud management software like RightScale (disclaimer: I work there). We released our permissions feature last January. It allows you to create different teams and environments and attribute them privileges on a granular basis. It means you can grant different permissions to different people. You can learn more on this blogpost.
Scalr is available as a hosted service which includes support. If you are looking for a free solution, you can download the source code, which is released under the Apache 2 license, and install it your self.
As mentioned earlier, RightScale and enStratus are two other alternatives.