Prevent an elastic beanstalk app being downloaded using the AWS account? - amazon-web-services

Short background, we're a small business but our clients are much larger businesses. We have some software they subscribe to which is deployed to AWS elastic beanstalk. Clients have their own devops teams, unlike us, and will need to manage some of the technical support. They will need access to the AWS account running the software, so they can do things like reboot the server, clear the database if they screw it up, change the EC2 instance type etc. This is OK but we want to prevent the software being downloaded outside of the AWS account.
The software is a java WAR running on Tomcat, on a single elastic beanstalk instance. We only care about limiting access to the WAR file (not the database for example).
The beanstalk application versions page appears to have no way to download the WAR file - which is good. They could SSH into the underlying EC2 instance though so presumably they could just copy the WAR out of the tomcat directory. Given the complexity of AWS there's probably other ways they could get access the WAR file too (e.g. clone the EBS volume and attach to another EC2 instance).
I assume that the machine instances available for purchase via AWS marketplace must have some form of copy protection but I've not been able to find any details on this. Also it looks like AWS only accepts marketplace vendors who are much larger than us, so marketplace option may not be open to us.
Any idea how I could prevent access to the WAR file running on elastic beanstalk while still allowing the client access to the AWS account? (Or at least make access hard).

The only solution that comes to mind for this would be, removing any EC2 SSH Key Pairs from the account, and specifically denying them access to ec2:CreateKeyPair. Really, what you need to be doing is granting them least privilege access to the account, that is, specifically granting them access only to those actions they absolutely need.
This will go a long way, but with sufficient knowledge of AWS, it's going to be an uphill battle trying to ensure that you give them enough access to do what they need, while not giving them more than you want. I'd question if a legal option (like contracts, licenses, etc) would be a better protection for this.

Related

How to add some new code to an existing EC2 instance

Bear with me, what I am requesting may be impossible. I am a AWS noob.
So I am going to describe to you the situation I am in...
I am doing a freelance gig and was essentially handed the keys to AWS. That is, I was handed the root user login credentials for the AWS account that powers this website.
Now there are 3 EC2 instances. One of the instances is a linux box that, from what I am being told, is running a Django Python backend.
My new "service" if you will must exist within this instance.
How do I introduce new source code into this instance? Is there a way to pull down the existing source code that lives within it?
I am not be helped by any existing/previous developers so I am kind of just handed the AWS credentials and have no idea where to start.
Is this even possible. That is, is it possible to pull the source code from an EC2 instance and/or modify the code? How do I do this?
EC2 instances are just virtual machines. So you can use SSH/SCP/SFTP files to and from. You can use the AWS CLI tools to copy stuff from S3. Dealers choice...
Now to get into this instance... If you look in the web console you can find its IP(s), what the security groups (firewall rules), and the key pair name. Hopefully they gave you the keys. You need these to SSH in.
You'll also want to check to make sure there's a security group applied that has SSH open. Hopefully only to your IP :)
If you don't have the keys you'll have to create an AMI image of the instance so you can create a new one with a key pair you do have.
Amazon has a set of tools for you in Amazon CodeSuite.
The tool used for "deploying" the code is Amazon CodeDeploy. By using this service you install an agent onto your host, then when triggered it will pull down an artifact of a code base and install it matching hosts. You can even specify additional commands through the hook system.
But you also want to trigger this to happen, maybe even automatically? CodeDeploy can be orchestrated using the CodePipeline tool.

AWS share custom AMI build instructions

I want to use a trusted cloud provider (I chose Amazon, maybe there is an alternative) to share an application without leaking its code.
The application is supposed to use the customer data, and I want to prove to him that I am not using his data for any other purpose.
So, is there any way to ask Amazon for publishing the instructions I followed to create an Amazon Machine Image which contains the application so that the user can happily instantiate the machine send it his data without any fear of any misuse?
Please help me, thanks a lot
You can create an AMI and grant permission for your user to launch an Amazon EC2 instance in their own AWS Account that uses that AMI.
Any data they place on the instance will remain within their AWS Account and you will not have access to it.
However, they might argue that there could be some software installed in the AMI that secretly sends their data to another computer on the Internet, so they might prefer to install the software themselves rather than use a pre-built AMI. However, unless they look through your entire source code, they wouldn't know whether your software itself is stealing data, either!

Securing Folder on EC2 Amazon Marketplace AMI

I'm planning to start a small business and submit an Linux AMI to Amazon's AWS Marketplace. As I'm reading the seller's guide, I see this:
AMIs MUST allow OS-level administration capabilities to allow for compliance requirements, vulnerability updates and log file access. For Linux-based AMIs this is through SSH." (6.2.2)
How can I protect my source code if anyone who uses my product can SSH to the machine and poke around? Can I lock down certain folders yet still allow "os-level administration"?
Here is a bit of context if needed:
I'm using Ubuntu Server 16.04 LTS (HVM), SSD Volume Type (ami-cd0f5cb6) as my base AMI
I'm provisioning a slightly modified MySQL database that I want my customers to be able to access. This is their primary way of interacting with my service.
I'm building a django web service that will come packaged on the AMI. This is what I'd like to lock down and prevent access to.
Whether or not you provide SSH access, it'll always be possible for your users to mount the root EBS-volume of your AMI on another EC2-instance to investigate its contents, so disabling SSH or making certain files unreadable for an SSH-user doesn't help you in this regard.
Instead of trying to to keep users away from your source code I suggest you simply state clearly what the users are allowed to do with it and what not in the terms of service.
Even large companies provide OS-images which contain the source code of their applications (whenever they use a scripting language) in clear form or just slightly obfuscated.

Boot strapping AWS auto scale instances

We are discussing at a client how to boot strap auto scale AWS instances. Essentially, a instance comes up with hardly anything on it. It has a generic startup script that asks somewhere "what am I supposed to do next?"
I'm thinking we can use amazon tags, and have the instance itself ask AWS using awscli tool set to find out it's role. This could give puppet info, environment info (dev/stage/prod for example) and so on. This should be doable with just the DescribeTags privilege. I'm facing resistance however.
I am looking for suggestions on how a fresh AWS instance can find out about it's own purpose, whether from AWS or perhaps from a service broker of some sort.
EC2 instances offer a feature called User Data meant to solve this problem. User Data executes a shell script to perform provisioning functions on new instances. A typical pattern is to use the User Data to download or clone a configuration management source repository, such as Chef, Puppet, or Ansible, and run it locally on the box to perform more complete provisioning.
As #e-j-brennan states, it's also common to prebundle an AMI that has already been provisioned. This approach is faster since no provisioning needs to happen at boot time, but is perhaps less flexible since the instance isn't customized.
You may also be interested in instance metadata, which exposes some data such as network details and tags via a URL path accessible only to the instance itself.
An instance doesn't have to come up with 'hardly anything on it' though. You can/should build your own custom AMI (Amazon machine image), with any and all software you need to have running on it, and when you need to auto-scale an instance, you boot it from the AMI you previously created and saved.
http://docs.aws.amazon.com/gettingstarted/latest/wah-linux/getting-started-create-custom-ami.html
I would recommend to use AWS Beanstalk for creating specific instances, this makes it easier since it will create the AutoScaling groups and Launch Configurations (Bootup code) which you can edit later. Also you only pay for EC2 instances and you can manage most of the things from Beanstalk console.

Same code for AWS and local application

I want to create Java application with use of Amazon Web Services and I also want to have ability to run it as local application. So it will be in two versions: Amazon cloud and as local application. I don't know AWS yet and I'am worry about if there is some specific api or database access so I couldn't run as local app. I simply do not want to write two separate versions of that app, or just write as less as possible.
Is it possible?
In EC2, you can launch virtual servers (or instances) with root or administrator access. That means your EC2 instances are capable of running mostly everything you can run locally.
There are no specific APIs to learn to run Java code on EC2. Just compile and package your code, upload it to your server (using scp/rsync/anything else you might be more used to), then run it with java -jar myapp.jar, after installing Java on the instance. You can also upload the source code directly into your instance and compile it there if you want. It really behaves like a "normal" server.
About database access, again, it works exactly as you would expect: just install your database server on the instance, say, MySQL, and connect to it normally (using JDBC for example). Also, note that there's a service called Relational Database Service (RDS), which simplifies the deployment and management of a database system: you don't have to install your database software, maintain it, upgrade, backup, etc, everything is done for you. You simply specify the name and password of the "master" user, and it gives you back a connection string. (and there's also a "micro" RDS instance which is included in the free tier so that you can start exploring for free!)
Finally, if you don't want to launch and maintain a virtual server by yourself, you could use Elastic Beanstalk, which automates lots of things for you: using the web interface, you simply upload your ".war" file, and Elastic Beanstalk launches and instance for you, installs Java, Tomcat, deploys your application, and monitor it for you -- you get emails in your inbox if anything goes wrong. There are tons of other features included in Elastic Beanstalk, and it is all completely free (you just pay for the servers it launches -- also, if you instruct it to launch at most a single t1.micro instance, which is included on the free tier, again, you pay nothing!)