(disclaimer: new to AWS, a developer trying to pivot into DevOps)
During one interview/screening, I took a take-home challenge, which asked me to provision a complex piece of infrastructure, using their own script, which relied on Terraform, and created a little cosmos of intertwined AWS resources. Unfortunatelly, I manually (yuck!) deleted the S3 bucket used by Terraform to keep track of the state of things - so destroying them automatically is no longer possible, so I need to clean it all up manually.
Most of the things are cleared now. But there's a Security Group that's left over. Deleting it fails due to it being connected to something called Network Interface. Looking at that Network Interface I found out that "Delete" button is greyed out, but "Detach" is active - alas, it said I can't "Detach" it, because I "lack permissions". Given the fact that I'm logged into console as a root of my AWS account, I don't buy it.
Does anyone know what these beasts are, and what are the possible problems killing them? I suppose it's kinda like a connection between A and B, and if either end of a connection is plugged in, you can't "kill" it - but what should I look for?
Got the bugger!
As I was clearing out the Roles created by Terraform, I discovered a Service-owned role; it had "RDS" in it's name. Surprised (I thought I killed those among the first), I went to check, and indeed there was an instance lurking. After killing that, removing NI and VPC (and the role) was unblocked.
It's interesting to me now - how come the error didn't mention the RDS as a blocker? All it could tell me was the NI is blocking it; now I guess I know who was the owner of the Attachment - that RDS instance. But why the heck was it a "permission" issue for me? 'Force' should have dealt with it!
Related
I am trying to understand how code deployments work with aws blue green stacks. I have been reading alot of documentation on it and the concept of it makes sense. So I understand that we have two environments (stacks) that are replica of each other. When I make changes and deploy it, the changes get applied to the inactive region and then when I activate it, the inactive region will become active and active region becomes inactive.
However I am not sure about the roll back process:
So my questions are:
If i am using an load balancer and lets say after i went to production some calls started to fail. However I know that my inactive stack (old version) is still healthy then how would i go on about manually telling the traffic go to my inactive stack or how do make that stack active again with the old changes?
Is there a better way to do it using route53? If can I just change the dns of the route to be dns of the old stack and will that work?
I am still new to aws and trying my best to understand it so if I didn't explain things clearly please let me know in comments and I will try to clarify further.
I've recently implemented some compliance in a company but one rule messed up my mind.
It is about iam-user-unused-credentials-check that, at least according to docs, should enter non-compliant if IAM user has used neither password not access key for configured amount of time.
Well, I do have a user that used his login credentials to access web console and it's stil
marked as non-compliant? I ran manually re-evaluate couple of minutes after that fact but still resource is non-compliant :/.
Should I give it more time and re-eveluate again in few hours? Or did I misunderstood what this rule does or how does it to that?
Ok, I understand what happened.
With this particular rule, AWS Config does not rely on configuration changes it records but on AWS Cloud Trail to see an activity. That's one.
The other one was the timeout that had to pass to pick up a trail (heh). After a while, resource just went compliant.
I am receiving the following when I try to add new AWS accounts to my newly created organization. Any thoughts on how to tackle this problem?
Make sure that your account has a complete billing profile, including payment information. If that is the case, and you are still having issues, AWS support will be able to help you identify the issue.
If this error occurs, wait for few minutes and retry. If it comes again contact AWS support. They will fix the issue mostly in 24hours time.
There is a clear message on the top, that your organization is in initialization status. Because of that you should wait until it's done initializing (in some cases it could take about an hour) and try again. AWS Documentation states (see step #7. Create), that
If you get an error that indicates that you can't add an account
because your organization is still initializing, wait one hour and try
again.
Therefore there is no need to contact a support for this kind of problems.
Is there a way to nuke all existing settings in an AWS account to begin again on a clean slate?
I an AWS beginner and after getting tangled up and my web site no longer loading, I need a clean slate to start afresh i.e. delete all AIM, ECS, S3, Load balancers etc all in one go.
I would suggest https://github.com/rebuy-de/aws-nuke - it can clean everything from every region and is the best tool I've found yet!
Probably not. This is a common safety + security mechanism in such complex and important systems: nobody should be able, by accident or otherwise, to quickly and easily delete everything. Using an infrastructure as code process, however, you would be able to do this by simply declaring the entire stack as unwanted. This is relatively safe for the simple reason that you can usually bring this kind of infrastructure back up again in a short time span, as long as care was taken during development to make sure that any permanent state cannot be irrevocably destroyed by infrastructure declaration changes.
Currently I log into IAM and edit policies by hand for my S3 bucket. When I change something in the editor, I have no idea what the policy was before unless I exit the editor by canceling and then go back and view it. So there's no way to tell exactly what I've changed. So editing is kind of painful, especially considering that I sometimes find myself changing something and then testing the change, with no trivial way to roll back to where I started.
Another problem created by the lack of version control is there's no log of why or when a particular permission was modified. For example, I would really like to know that the reason we need the ListBucket permission on our bucket is because that was required to get file uploads to work. You know, the kind of thing you might put in a git commit message.
Now that you understand and care deeply about my motivations, I would like to know how best to get my policies into git. To the extent possible, I'd like the only way to change the permissions to be through code that is written by me, with the presumption being that any time you make a change, you commit to the repository. This is not perfect security of course, but it does provide an accounting of what changed when, and gives us a single place where we make changes.
Here's my proposal:
Create an IAM user called policy_editor
Revoke policy editing privileges from all users
Give policy_editor policy editing privileges
Do not give policy_editor a password (thus have to use api credentials to change policies)
My questions are:
Is this possible? (Ideally even the root user wouldn't have permission to edit policies, so that wouldn't happen by accident)
Is this a good idea?
Is there a better solution?
Is there a tool that does this already?
Thanks!
Is this possible?
Yes, the API is flexible enough to do that. Writing automation around IAM pays off in spades.
By "root user", do you mean the AWS access keys directly on the account? Step 1 is to delete those creds (directly on the account) and only use IAM users for everything.
http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
Is this a good idea?
Yes, automation is good.
Is there a better solution?
Well, here are some related ideas:
Use CloudTrail to log all IAM changes.
If you disable your IAM-changing privs, create a second user (with MFA enabled) for emergencies.
For some "dangerous" commands, use automation instead. (i.e. give them a web form where they can delete a bucket, but your code verifies it's OK to delete beforehand.)
Avoid adding privs directly to people. Always use groups to organize permissions. Don't be afraid to spend some time figuring out what logical permission groups would be. For example, you could have a "debugging production" group.
Don't get too fine-grained (at least not at first). There is a trade-off between security and bureaucracy here. If people have to ping you for every little permission, they will start requesting privs "just in case".
Use the conditionals: You can say "you can delete any bucket that doesn't have 'production' in the name". Or "You can terminate instances, but it requires MFA".
Review your policies regularly. People move around between teams, so people often end up with permissions they don't need. If your groups are well-named, you can make the managers review the permissions needed for their underlings.
Is there a tool that does this already?
Not that I know of. It's pretty easy via API calls, so someone is going to write it.
(This guy started a project: https://github.com/percolate/iamer )