I'm setting up an EC2 instance and an Amazon RDS database to host a .NET website. I want my third-party webmaster to handle its setup, but once he has completed setup and the website is running, I want to remove his access to EC2 and RDS completely.
All I want to give him access to is RDP in EC2 with root access in case he needs to install extra software and the ability to create and edit tables within an SQL database in RDS. He does not have any role in managing and modifying EC2/RDS instances.
I've tried allotting IAM access with groups and all but I can't figure out how to myself retain superuser access while I remove him once he is done setting up the web server and SQL database. How do I give him temporary revokable access while I maintain superuser access that will not be affected even if I remove him from IAM?
Amazon IAM won't help you with what you want to do.
IAM is used when you want to restrict and/or allow access to the upper-level management of the resources through the AWS Management Console and/or the AWS API.
However, what you want to do is control access to the internals of your resources (EC2 instance(s) and RDS instance). For these, you need to do them using their own internal security controls:
For your RDS instance, create a non-admin user with just enough permissions for them to accomplish what they want to do. For example, if your RDS instance is MySQL, then give them INSERT, SELECT, UPDATE, DELETE, CREATE TABLE, etc. permissions. Do not give them the ability to create/modify users or anything administrative like that. Best practice is give them permissions for as little as possible and add permissions (if you think it's OK) as they ask for them.
For your EC2 instance(s), do not give them root access. Create a non-root user specifically for your webmaster. Give that user "just enough" permissions to install the website. Do not allow them to use
yum
orapt
. Instead, if they need it, they should tell you and you can do it as root.In both cases, once your webmaster is done, delete their users and close the security group(s) to them.
Never give root/admin access to a third-party. There are many reasons, but the primary ones are these: