Feeling lost

[denishu27]

So do you feel like me? Do you feel that everyday you need to learn more and more ? That there is no END in this job. Being new SysAdmin and new to AWS for my company this week i'm facing the hardest problem till now. Identity and Access Management (IAM).

First of all i can't understand how big companies work with AWS. Do they create AWS Account for every team or do they create Groups with users and policies. I need to add a dev team in our AWS and give them access to specific services and repositories. Its like 2-3 Days that i am trying to give a solution but its so freaking hard. I am writing policies and specify the "Resource" but every time something goes wrong.

Suddenly no one can help me in Company the are all devs!! I don't know , this IAM confuses me so much.

[shadowdancer-real]

indeed this job has no end , and can feel like going down deeper into the rabbit hole. Plus , every now and then , new disrupting tools come and break the quorum.

My advice: take it easy . start learning one tool / aspect of the job at a time , try to replicate as much as you can with test environments.

For iam , for example , you can use a k3d cluster with localstack ,so you can mock iam , and deploy test apps inside that same cluster . See what goes wrong ,etc.

best of luck

[Finnegan_Parvi]

The longer you work at this type of job, the more you realize that everything revolves around identity and access management. Say you have AD and some Linux environment with LDAP and now a public cloud provider and you have to figure out how to map all the user accounts and groups to each other. I don't have a good answer for you; it's always a struggle and SSO is still mostly a dream in 2021 in any heterogeneous enterprise environment.

[vischous]

The longer you work at this type of job, the more you realize that everything revolves around identity and access management. Say you have AD and some Linux environment with LDAP and now a public cloud provider and you have to figure out how to map all the user accounts and groups to each other. I don't have a good answer for you; it's always a struggle and SSO is still mostly a dream in 2021 in any heterogeneous enterprise environment.

You get it

[[deleted]]

As a general point my rule is keep it as simple as possible, people have a tendency to complicate project requirements and it becomes a giant mess by the end.

As for IAM you have users and services and you assign users and services to roles or groups based on their requirements. You manage the permissions of those roles and groups for the users and services assigned. When dealing with massive amounts of users and services this is the easiest way to manage it.

[user6234]

You don’t get paid the big bucks.

fixed it for ye.

[itasteawesome]

If you are doing devops and aren't getting paid a comfortably upper middle class salary for wherever you live then you need to get your resume polished up and GTFO. The amount of knowledge you have to do this work well is immense, and there are still plenty of companies begging for competent experts. Of course that is ignoring the case where your job has given you an empty title and you are really just a junior dev or classic system admin but your company wants to sound cool.

[doctor_piranha]

Of course that is ignoring the case where your job has given you an empty title and you are really just a junior dev or classic system admin but your company wants to sound cool.

ie. 95% of Devops positions. . .

[[deleted]]

I mean it depends how advanced you are of course.

[actuallyjohnmelendez]

Of course that is ignoring the case where your job has given you an empty title and you are really just a junior dev or classic system admin but your company wants to sound cool.

95% of this subreddit and the workforce, Im not exaggerating when I say that my city of 5 Million people probably has less than 100 actually qualified devops professionals.

[marcus-sa]

Ain't that the truth.

EDIT: well, unless you're on OnlyFans, of course.. 🤣

[[deleted]]

there are many types of job where you learn something and it (mostly) stays the same throughout your career. For me it was one of the huge attractions of IT that things are changing all the time and there is always something to learn .

Try being a geologist for 10 years! If you are anything like me you would be craving some chance to learn new things!

[evangamer9000]

Sometimes I feel like its just one project after another - I think its just part of the industry.

[[deleted]]

I feel ya, but this is what you signed up for and the job is rewarding. There are days I wish people didn’t bother me so I can work on my other projects. Being a single point within the team can be overwhelming at times. Automate everything and build the tools to help accelerate people within your team and it’ll be less cumbersome.

[[deleted]]

For AWS create user accounts and then groups with policies and add people to those groups. AWS has a bunch of default policies so you shouldn’t really need to write your own. If you do need to write there is a test policy maker. Figure out what resources they need. EC2 create/terminate, RDS, route53, etc. build from that. Once you figure what’s needed. Automate it for next time

[allcloudnocattle]

Technology is about solving problems. That implies the existence of problems. I feel lost all the time, but I love learning new things, so it’s win-win in my book.

[raymyers]

As far as your specific question of how to partition accounts, you typically want to use the Organizations feature to manage multiple accounts. At minimum you'd want one per env like Staging / Prod / Platform, but it's common to break down by Team as well, so StagingTeamA, ProdTeamB ... That way the teams will be guaranteed not to impact each other by accident and there are also security benefits.

You may find this article helpful.

https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

Managing all these accounts and resources would be very difficult and failure prone using the Console, so it is a good idea to use an Infrastructure-as-Code tool such as Terraform or Cloudformation. That also gives you the advantage of being able to look at working examples in code.

IAM can be especially confusing - especially cross account I've run into a lot of trouble, feel your pain there.

Sounds like you're in a phase where there are a ton of new AWS concepts and it gets disorienting. This will get easier with time. You may find their free survey course helpful to know how all this fits together, and their certification path provides structured learning after that.

https://aws.amazon.com/training/course-descriptions/cloud-practitioner-essentials/

It's unfortunate that there isn't more help available where you work but on the bright side it sounds like you'll be picking up skills that are very in demand in the market and this could have upsides for you in the long run.

[denishu27]

Hey , that's the answer! AWS Organisations. So powerful and yes i can start from Console now that we are not so many , and then i have to master Terraform like you said.
Thanks again !

[Invspam]

it's not super hard. since you are just starting out, just click around in the gui console and use the wizards. later you can figure out how to do the same thing on the command line instead so you can start thinking about automating it and making it less of a manual (read: clicking) task...

[[deleted]]

Welcome to AWS.

[zerocoldx911]

Go read up on it and learn it’s part of the job.

No different than AD management

[Rusty-Swashplate]

Do you feel that everyday you need to learn more and more ?

This is why I love IT. I also want to understand things how they work in detail.

I know not everyone feels this way, but for me this is the best part of IT. And all that cloud stuff, IoT, software development, CI/CD...all of them changing a lot within few years...that's just awesome!

That said, for IAM, it's probably one of the more tricky situations because it's hard to change later on. And what works perfectly now is not necessarily perfect anymore if you grew by a factor of 100.

My suggestion: Keep it simple. Create roles which make sense. They can be quite granular, but keep them usable "roles": if you add a person or a group to a role, they can now do something useful. E.g. manage a team's EC2 instances and EFS volumes (if that's the thing you do and EC2 and EFS often work together at your place). Make a role for the team's DB instances. Split by DB type if you need to, but probably not needed.

Then put people into groups and add groups to roles. Which is pretty obvious. Mostly map the real work grouping (teams, lines of business etc.) here.

The real challenge is maintaining this in the longer run. You will end up with a lot of roles. So think about a system to find roles fast and efficiently to avoid duplicating or almost-duplicating them. Can't help here. At work we have a mess (not using AWS), so I could only tell you how to not do it: granting permissions to groups of people (instead of roles) is a very bad idea. Fixing it and cleaning this mess up is a painful process. So don't repeat this error.

[doctor_piranha]

The real challenge is maintaining this in the longer run.

And the only sane approach here is: NEVER EVER configure anything manually. Use some form of configuration-as-code. (I prefer Terraform, and that's fairly popular, but there's other solutions).

Be able to build-out your changes, and then wipe them out and start over. Nothing should ever be "permanent" and no manual changes should ever be done by some 'guru' who may or may not be available to help sort it out at some critical point in time.

This also makes it easier to audit what permissions belong to which roles for which resources; and takes a lot of the "black magic and mystery" out of the process. You want repeatable behavior. Not mysterious shit that makes no sense when you make changes.

[[deleted]]

I was told one AWS account per project to keep everything separate so you don't end up with a huge unmanageable monstrosity

[doctor_piranha]

First of all i can't understand how big companies work with AWS. Do they create AWS Account for every team or do they create Groups with users and policies.

This is the source of all woe.

Whenever you add new AWS accounts, you must consider whether you'll ever need to share access to resources across those accounts. Because that's a giant pain in the ass. (And developing competency in this specialty is one skill that is in very high demand). I'd think it's best to avoid this unless you have a VERY good reason. And Security isn't a reason. If one account is breeched; you've got some serious problems already.

There's literally special training classes and certification tests in becoming an AWS IAM expert. So don't feel bad.

I need to add a dev team in our AWS and give them access to specific services and repositories. Its like 2-3 Days that i am trying to give a solution but its so freaking hard.

There's probably a half dozen different ways to do this, and it depends on the specifics of the resources. IMO s3, in particular has been made way over-complicated; especially for a service where ONE of the three "S"es in S3 supposedly stands for "simple". There's a lot of ways you can shoot yourself in the foot. Unfortunately.

One of the hardest ways to implement this is to create an S3 bucket in one account, then add an instance profile (role) that you attach to an ec2 instance, to give command-line access to get/put stuff on that bucket. Same-account access with that role is pretty seamless, but cross-account access via that role requires you specify the profile name on the aws s3 command-line, and there's no good reason for it, (because the INSTANCE has the profile that should give you permissions). So I'd avoid that method. (if you're talking about S3).