|
No identity center, just plain IAM users signing into the web console or using access keys from the command line.
|
#
?
Feb 14, 2024 20:41
|
|
|
|
| # ? Apr 28, 2024 13:42 |
|
|
it's easy to assume roles from the cli and web ui. whether or not that's a good idea kind of depends on how many roles you think people need / why they can't just have PowerUserAccess with some deny policies instead.
|
|
#
?
Feb 14, 2024 20:55
|
|
|
I would long term look into identity center, as its going to solve a lot of problems that will seem to come up. Every company started out with "just a few things in AWS" and then had it blossom into a huge mess. Preempt that by getting identity center setup first. In the meantime, if it were me, I'd opt for scoped roles, and a few custom policies as needed.
|
|
#
?
Feb 14, 2024 20:57
|
|
|
Identity Center is probably in the future, though how far in the future is certainly up for debate. The joys of a tech company still somewhat in "startup" mode that only recently hired an "IT guy" to get Okta going, for example. Who is not me, I'm the latest DevOps person. At least all of our IAM access is controlled via Terraform, so that feels better than nothing. There is not an easy win here though, I think I'm just gonna pretend to forget about it for a little while and work on something else.
|
|
#
?
Feb 14, 2024 21:25
|
|
|
FISHMANPET posted:My read on those is that you have to "switch" into a role and isn't really meant to be a user's level of regular access. And it still has a policy attachment limit. It was like 5 years ago now so my memory is hazy. But I stood up an AWS org with a few dozen accounts without SSO/Identity Center (I kind of forget why, I think like you that company's IT SSO story was just nonexistent at that point). Amazon's guidance at the time was to have one account that held all the IAM users, whether that was the organization root or just a dedicated "identity" account. Those users don't have permission to do poo poo except assume roles in other accounts. If you wanted to do something in ProductionServiceA, you'd auth as your IAM user then assume the Operator or ViewOnly or whatever role was appropriate in the ProductionServiceA account and do your thing. You'd include trust policies to control who could assume what role. If this sounds like a lovely, hood-rear end reimplementation of SSO, it totally was. We wrote some simple tooling to make the flow a little less horrific for devs but Identity Center really smooths this all out and is worth the time to stand up. You don't need to run things like it's 2018 anymore, the AWS auth experience has gotten orders of magnitude better. Also buyer beware on those managed IAM policies. Amazon absolutely does not keep them up to date with new services and features. At some point you're going to need to tack on your own custom policies anyway that cover random gaps where AWS released new things and then just...never went back and added them to the policies. Not saying you shouldn't use them, they're still helpful, they're just not a silver bullet.
|
|
#
?
Feb 14, 2024 23:34
|
|
|
FISHMANPET posted:My read on those is that you have to "switch" into a role and isn't really meant to be a user's level of regular access. And it still has a policy attachment limit. The policies attached to roles is a soft limit though, they can increase it upon request
|
|
#
?
Feb 15, 2024 16:46
|
|
|
It looks like both users (I would assume this also applies to groups) and roles have an initial limit of 10 policies and a hard cap of 20. So yeah you could request an increase and relieve the immediate pressure. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html Having 20 policies on a single object feels a bit nuts though and at some point you do need to take the time to just craft your own policy that does exactly what you want. IAM janitoring is basically the Eating Your Vegetables of using AWS, in that it's not a lot of fun but pays dividends in terms of the health and safety of your cloud environment.
|
|
#
?
Feb 15, 2024 17:20
|
|
|
Docjowles posted:Having 20 policies on a single object feels a bit nuts though and at some point you do need to take the time to just craft your own policy that does exactly what you want. IAM janitoring is basically the Eating Your Vegetables of using AWS, in that it's not a lot of fun but pays dividends in terms of the health and safety of your cloud environment. Absolutely! Scope your roles appropriately, making your own custom policies is 100% worth doing. There are a lot of tools out there (names escaping me ) that can basically look back at what API calls a principal has made and then give you a recommendation as well.
|
|
#
?
Feb 15, 2024 17:27
|
|
|
BaseballPCHiker posted:There are a lot of tools out there (names escaping me ) that can basically look back at what API calls a principal has made and then give you a recommendation as well. The AWS-provided one is Access Analyzer: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html. I think Netflix's repokid was the precursor but Access Anazlyer's pretty good. I wish I could find it again but I think Netflix also promoted an IAM Policy pattern that was basically "make a policy per-principal" since trying to make "shared" cross-cutting policies to attach to multiple principals inevitably diverged and since you're managing these policy in some declarative/IaC fashion (right?!) then having a policy-per-principal actually make change tracking / control easier. (This advice is primarily targeted at workload roles.)
|
|
#
?
Feb 15, 2024 18:54
|
|
|
Are any of you Amazonians(?) close to Redshift? Do you know of any good blogs and/or consultants that work with Redshift? It seems to be a large pillar in the AWS business but I don't really find much community stuff on it the way I do SQL Server, or Postgres etc...
|
|
#
?
Feb 17, 2024 04:49
|
|
|
i work with it daily. not sure where you're at with it, but it's basically postgres scaled. i don't know any consultants for it and i constantly struggle to find specifics. to be honest, that's kind of true of all things aws. support and community are very lacking, especially compared to sql server or mysql. also, are we talking redshift serverless or straight-up redshift? biiiiiiig difference in my experience. specific questions about it? i can tell you it's not as good as sql server!
|
|
#
?
Feb 17, 2024 05:11
|
|
|
abelwingnut posted:i work with it daily. not sure where you're at with it, but it's basically postgres scaled. I'm trying to figure out what I want to pivot to when I leave my current role. I like big data. From the outside looking in, Redshift seems like a cool piece of tech. I know it catches a lot of flak from Reddit and Hackernews but I don't have enough experience with it to argue one way or another. Are you an administrator, or reporter writer, or somewhere in the middle? Do you see a lot of job opportunities in the market with being a redshift specialist?
|
|
#
?
Feb 17, 2024 05:19
|
|
|
i'm not a redshift admin, but was previously a sql server admin. i now do more architecture-related things. in order to be the best true redshift admin you can be, you need to know much more beyond redshift. you really need to know like the top 10 aws products, through and through, and know how they interact with redshift. in my experience, the left arm of aws products doesn't talk to the right arm of aws products a lot of the time, and you can easily get caught in situations where your obvious isn't so obvious to others. that said, aws is so vast you can always finagle a solution to whatever problem you might have. but this also demonstrates a fundamental problem with aws. one product doesn't really have the same direction as any other product, so there's almost always some conflict. an example--redshift and quicksight. quicksight is aws's tableau. i feel i should be able query redshift seamlessly. yet, i've run into constant issues doing so. like, you want to run a SET from quicksight? good luck! but that's me approaching it from a sql server logic. if you only know aws and that world, you're probably fine. i don't know. i'm not the biggest fan of aws and would rather stick in sql server. but, and getting to what you're alluding to, aws is 'the future' per the bigger tech companies, no matter how bad it is now. aws is going nowhere, and it's constantly expanding in both smart and stupid ways, so yea, i would say there's a market for database skills in aws. but the job market for tech is kind of lacking already so...might not be the best time to move. abelwingnut fucked around with this message at 06:11 on Feb 17, 2024 |
|
#
?
Feb 17, 2024 05:54
|
|
|
FISHMANPET posted:Identity Center is probably in the future, though how far in the future is certainly up for debate. The joys of a tech company still somewhat in "startup" mode that only recently hired an "IT guy" to get Okta going, for example. Who is not me, I'm the latest DevOps person. At least all of our IAM access is controlled via Terraform, so that feels better than nothing. Implement identity center the second you get okta up. It’s not the future, it’s the present, and it is the recommended way to handle authentication by humans to AWS roles. It’s very easy to set up and extraordinarily useful for segmentation of privileges and ease of assuming the relevant roles. Roles are the primary mechanism you should typically be using for identities in AWS - whether human or service based. Death to IAM users. You can often literally get away with 0 of them.
|
|
#
?
Feb 17, 2024 06:10
|
|
Cat Army 
|
Docjowles posted:It looks like both users (I would assume this also applies to groups) and roles have an initial limit of 10 policies and a hard cap of 20. So yeah you could request an increase and relieve the immediate pressure. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html It's nice being able to see the permissions sort of grouped into their purpose though. I could craft one giant policy with all of them combined but it just seems like it's less organized. Why don't they just group them up behind the scenes for me?
|
|
#
?
Feb 17, 2024 18:39
|
|
|
I’m guessing a lot of weird limits boil down to 1. A decision made like 15 years ago that is a total bitch to change now. 2. Something that seems reasonable in your one account but multiplied by 10 billion IAM objects or whatever becomes A Problem. Or the combination of both. Not trying to carry water for Amazon, though, since they certainly have the resources to do pretty much anything if they want to. You can at least kind of break up your policy into statements with a Sid describing the purpose but that’s not great.
|
|
#
?
Feb 17, 2024 21:03
|
|
|
For one of my accounts I received a billing alert stating that mysql 5.7 is EOL and since I’m running 1 or more instances the account will be opted in for extended support. The mail mentions account id and region but no ARNs. I only run a few dbs in that account and all of them have been upgraded to 8.x months ago. I do have the pre migration snapshots which were made on an even older version. Could those trigger such a warning? The health dashboard shows the same billing alert but also no ARNs. Just a prediction of the extended support costs.
|
|
#
?
Feb 17, 2024 22:34
|
|
|
i would simply ask aws support tbh
|
|
#
?
Feb 18, 2024 00:01
|
|
|
abelwingnut posted:i'm not a redshift admin, but was previously a sql server admin. i now do more architecture-related things. Thanks for the info! To me, the SQL Server community has to be one of the best professional groups out there. It's huge, and just about everyone is welcoming and willing to share knowledge and insights. I wish AWS had something similar with Redshift/Glue/EMR etc... I agree with your last point, the current tech job market is rough for my experience and skill set. My current plan is to hunker down at my current gig, build up my cloud skills, and make a jump if a good opportunity pops up.
|
|
#
?
Feb 18, 2024 18:37
|
|
|
Hughmoris posted:I'm trying to figure out what I want to pivot to when I leave my current role. I like big data. From the outside looking in, Redshift seems like a cool piece of tech. I know it catches a lot of flak from Reddit and Hackernews but I don't have enough experience with it to argue one way or another. Don’t specialize in a specific service or platform. AWS focuses more on categories of services, like “compute”, “serverless”, “SQL-based”, “NoSQL-based”, “networking.” So if you are looking to pivot, sit for one of the “____ specialist” certs (security, database, networking, storage, etc) start mucking around with the technology (save money by spinning up a VM for SQL Server, MySQL, Postgres, Cassandra, MongoDB, etc) and learn how they work and how they differ, what their strengths and weaknesses are and be able to talk to a grade schooler about what a database is. Then interview at AWS and become a SME and kill it.
|
|
#
?
Feb 20, 2024 01:18
|
|
|
Agrikk posted:Don’t specialize in a specific service or platform. AWS focuses more on categories of services, like “compute”, “serverless”, “SQL-based”, “NoSQL-based”, “networking.” That would be the dream. I genuinely enjoy helping people use technology to solve problems. I have my SAA cert and have been eyeballing the specialty certs. My background is Data so I'll probably go that route. Security isn't fun for me, and networking was never in my wheelhouse. Speaking of AWS... how's the vibes over there these days? Still a big freeze on new hires or is that all in the past? *Wow. Looks like AWS is retiring the Data Analytics AND the Database specialty certs in April. A new Data Engineering cert is coming online next month. Hughmoris fucked around with this message at 03:16 on Feb 20, 2024 |
|
#
?
Feb 20, 2024 02:45
|
|
|
Hughmoris posted:Security isn't fun for me. Do yourself a professional favor and at least check out the KMS section of any exam guide for that cert. It'll pay big dividends down the line.
|
|
#
?
Feb 20, 2024 03:22
|
|
|
Hughmoris posted:Speaking of AWS... how's the vibes over there these days? Still a big freeze on new hires or is that all in the past? Honestly? It’s a loving trainwreck in my part of the biz. Managers and skip levels are too busy looking customer obsessed to be customer obsessed. People are head-down trying to avoid being noticed lest they get swept up in silent firings so managers can make their force reduction quotas. People have been promoted to their level of incompetence and, where I once was driven to bring my A game so all the smart people wouldn’t find out how dumb I was, now I just shake my head at the rank stupidity that is allowed to run rampant. And yet leadership still clings to this tired notion of “Day One Culture”. We are a twenty year old company with a hundred thousand employees, there is so much internal process that IBM would blush, and the hiring bar has fallen so low that people misspell AWS (I poo poo you not). When I am left alone to do my job and actually help our customers I really love my job. But I spend all of my time on “giving back to the business” so my skip level can look good while he throws us under the bus so he can look even better. But the base salary is good, the stock is back on track to do interesting things, work-life balance is amazing, the benefits are solid and maybe I can do this for a few more years until retirement.
|
|
#
?
Feb 20, 2024 06:21
|
|
|
Im sure Im missing something dumb here.... Im writing a SCP to block anyone from launching new instances that use IMDSv1. Thats all well and good and working fine. Now I want to update the SCP so that someone with a specific role can launch an instance with IMDSv1 if the need should arise. Ideally I could do that by referencing an Identity Center Permission set. So anyone in any account with that permission set can go nuts with IMDSv1 if necessary. Except I cant see any way to do that! There has to be a way to do that I would think, or am I overthinking this? Should I just reference the role as it gets created in each account instead?
|
|
#
?
Feb 22, 2024 15:33
|
|
|
I'm running a container on ECS and would like to get the EC2 instance ID for logging. Container is running .NET core and the AWS SDK for .NET exposes a Amazon.Util.EC2InstanceMetadata.InstanceId but this appears to return null. I'm assuming this is because it's running in a container and not directly on the instance. Any idea what methods I can use to get this instance ID? Some stack overflow answers mention querying http://169.254.169.254/latest/meta-data/instance-id but 1) I'm not sure whether this will work from inside the container and 2) testing this requires trial and error on another deployment so I'd rather have some idea upfront if it will work or not
|
|
#
?
Feb 29, 2024 16:03
|
|
|
Dumb question but are you sure you're running on EC2 vs Fargate?
|
|
#
?
Feb 29, 2024 16:43
|
|
|
Happiness Commando posted:Dumb question but are you sure you're running on EC2 vs Fargate? Yep definitely EC2
|
|
#
?
Feb 29, 2024 17:02
|
|
|
I found this and it seems promising, if you don't want/can't use bash you could probably convert it to sdk https://gist.github.com/adiii717/fca85afe24f74a7259cf87ec058c00db
|
|
#
?
Feb 29, 2024 17:12
|
|
|
the documentation for this is here https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint.html
|
|
#
?
Feb 29, 2024 17:24
|
|
|
I've had similar behavior from EC2MetadataUtils called from an ECS task. Solution was to increase the LaunchTemplate HttpPutResponseHopLimit to 2 from the default 1. Discovered this when I changed the task networking awsvpc -> bridge mode. EC2MetadataUtils worked fine in vpc but gave a null InstanceId in bridge mode. (Bridge mode adds an extra 'hop' onto the host.)
|
|
#
?
Mar 1, 2024 06:31
|
|
|
Plank Walker posted:
Yes, that url is made specifically to be accessed from inside the service. Or, at least, that's how it works in EC2, and I would assume for ECS as well. It's all part of the metadata service.
|
|
#
?
Mar 1, 2024 06:41
|
|
|
BaseballPCHiker posted:Im sure Im missing something dumb here.... What would that need for IMDSv1 permitted instance be? We enforce it at the AWS account level - starting with lower environments, fixing whatever broke, and then eventually enforcing it in production.
|
|
#
?
Mar 1, 2024 07:38
|
|
|
fletcher posted:What would that need for IMDSv1 permitted instance be? We enforce it at the AWS account level - starting with lower environments, fixing whatever broke, and then eventually enforcing it in production. I needed a role that can be assumed that has permissions to launch imdsv1 instances still sadly. We have a few important vendor AMIs that are still using IMDSv1. I was able to get it done by using the role as a parameter and calling it that way.
|
|
#
?
Mar 1, 2024 13:43
|
|
|
Plank Walker posted:I'm running a container on ECS and would like to get the EC2 instance ID for logging. Container is running .NET core and the AWS SDK for .NET exposes a Amazon.Util.EC2InstanceMetadata.InstanceId but this appears to return null. I'm assuming this is because it's running in a container and not directly on the instance. So I figured out my issue, I needed to set ECS_ENABLE_CONTAINER_METADATA=true in the file /etc/ecs/ecs.config on the EC2 instances that were hosting my containers. The only way to do that that I could find was to add commands to the user data section of the auto scaling group configuration in cloudformation/CDK. This ended up populating the field Amazon.Util.EC2InstanceMetadata.InstanceId in my .NET code, so no need to mess around with reading and parsing JSON from the internal metadata URLs.
|
|
#
?
Mar 7, 2024 18:10
|
|
|
lol my coworker asked Amazon's Q AI assistant thing if Compute Savings Plans work for RDS and it said "yes because under the hood they run on EC2". That's... definitely not true, right? I wonder if they would issue a refund if you bought a useless savings plan on the advice of their dogshit hallucinating AI. of course not
|
|
#
?
Mar 7, 2024 18:23
|
|
|
That AI assist thing is so loving dumb and annoying. I feel bad for anyone at AWS who gets stuck working on that thing.
|
|
#
?
Mar 7, 2024 18:25
|
|
|
I want to see the legal precedent be that chat bots are representatives of the company that uses them, and so the company is liable for any claim they make. It would at least stop people from using them.
|
|
#
?
Mar 7, 2024 18:26
|
|
|
Yeah, does not cover RDS. Also lol. In Canada, not the US, but we're already seeing legal cases on this sort of thing. https://arstechnica.com/tech-policy/2024/02/air-canada-must-honor-refund-policy-invented-by-airlines-chatbot/
|
|
#
?
Mar 7, 2024 18:27
|
|
|
Docjowles posted:lol my coworker asked Amazon's Q AI assistant thing if Compute Savings Plans work for RDS and it said "yes because under the hood they run on EC2". That's... definitely not true, right? I wonder if they would issue a refund if you bought a useless savings plan on the advice of their dogshit hallucinating AI. I would put money on AWS refunding that savings plan. The console AI assistant is dumb as poo poo but Amazon doesn’t have health insurance/cable company level of disregard for customer sentiment.
|
|
#
?
Mar 8, 2024 00:53
|
|
|
|
| # ? Apr 28, 2024 13:42 |
|
|
Curious if Forrest Brazeal’s cloud resume challenge holds any weight in the industry? I’m almost done with it and have learned quite a bit with various services but was skeptical if it actually helps people during their job hunts.
|
|
#
?
Mar 8, 2024 01:02
|
|