|
crazypenguin posted:Fast possibly useless thought, but the error message "Adding cross-account target is not permitted." does not strike me as a IAM policy problem, but a limitation of what the service will accept. 12 rats tied together posted:haven't thought about it too hard but i want to note that when you're doing x-account access you usually can't rely on asterisk, you have to supply the account id of the other account Definitely not an IAM problem! Im starting to think cross account SNS isnt possible without SQS? Got to look into it more. Also a callback to several months ago when I asked about finding API calls around Marketplace subscriptions. They did finally release cloudtrail logging for this about two months ago! - https://docs.aws.amazon.com/marketplace/latest/userguide/logging-aws-marketplace-api-calls-with-aws-cloudtrail.html
|
#
¿
Sep 25, 2023 15:57
|
|
|
|
| # ¿ May 22, 2024 07:21 |
|
|
Got a weird one today I've never seen. A bunch of workspace instances are showing an account# via IMDS that is nowhere to be found in my AWS org. Like I can view their VPC IDs and confirm theyre in the right account but the host itself reports a different account. Really throwing off inventory for me.
|
|
#
¿
Dec 28, 2023 20:43
|
|
|
No creds or attached role. Googling around I do see some other people mention that account # in some GitHub pages here and there, so I wonder now if its some Amazon owned account#?
|
|
#
¿
Dec 28, 2023 21:19
|
|
|
Found my answer - https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html#architecture WorkSpace workloads have two ENIs and two VPCs. The compute part of the workspace actually resides in another aws managed account I had no clue but at least clears up that oddball issue. Thanks Ants posted:I've been dropped into a situation where someone has had their SES service suspended after AWS detected potential misuse. I'm 99% sure this is a "the horse is out the barn door" scenario and I am aware that email sucks, but is there any way to access a log of sent messages, the IP address making the request, how it was authenticated (e.g. access key used), subject line of the email, destination etc. or is that all logging that you have to configure yourself if you want access to the data? Oooft. CloudTrail will only capture the management events which may have some helpful info for you. Moving forward this may be helpful for you - https://docs.aws.amazon.com/ses/latest/dg/monitor-using-event-publishing.html
|
|
#
¿
Dec 28, 2023 22:15
|
|
|
Hmmm, AWS Amplify has a free tier component, thats probably the quickest/easiest way, but I wont pretend to be an expert and others with more experience can chime in. You could also go the full painful way and setup an ec2 autoscaling group, build out your own vpc with it, setup Cloudfront, etc. That would be a lot more work obviously but if you havent had any hands on AWS experience would be a good intro project to just touch a lot of common services.
|
|
#
¿
Jan 8, 2024 22:18
|
|
|
The solutions architect cert is the baseline go to in my opinion. It'll give you a good introduction to the most commonly used services. ACloudGuru is worth the cost for the sandbox environments if youre just starting out. It'll give you a chance to get some hands on experience without having to worry about leaving something on and getting a big bill later. Their other course offerings have gone down hill since they got bought by Pluralsight, but the solutions architect associate course is still fine.
|
|
#
¿
Jan 9, 2024 15:57
|
|
|
Speaking of IAM.... Anyone ever setup IAM Roles Anywhere? I sort of want to take on a project myself to get it and CA setup to put the final nail in the coffin for my remaining access key IAM users. But Ive got no experience with it, and I'm about to have baby brain and be out on paternity leave for a while so Im a bit hesitant to start it now.
|
|
#
¿
Jan 9, 2024 17:55
|
|
|
Just my two cents, but beanstalk has so many weird gotchas and limitations behind the scenes that its not worth using.
|
|
#
¿
Jan 10, 2024 20:09
|
|
|
I'm trying to put some of the final nails in the coffin of IMDSv1 here. I've got good reporting and metrics on which instances are set to IMDSv2 only, and have config rules ready to go to enforce that as well as an SCP. Looking at CloudWatch though I do see a ton of instances using IMDSv1, all on a regular cadence across instances in an account. My guess is that its something AWS is using. Is there an easy way to see whats actually musing IMDSv1 without installing the packet analyzer on these hosts?
|
|
#
¿
Feb 7, 2024 16:21
|
|
|
Its either AWS or our CSPM. I see IMDSv1 usage for thousands of instances, across multiple accounts, all at the same time. Was hoping for an easy button, but I guess its just time to use the packet analyzer.
|
|
#
¿
Feb 7, 2024 17:20
|
|
|
Well I ended up running the IMDS packet analyzer and its all basically instances assuming their roles. 99% of them in this case were set to support IMDSv1 or 2, and I guess by default then they just opt to use v1. So it should be pretty easy for me to get this switched over. For anyone else following along, the docs for the metabadger tool are more useful than whats provided by AWS as it will show you a few different options for running the tool - https://github.com/salesforce/metabadger
|
|
#
¿
Feb 12, 2024 18:05
|
|
|
Is there any reason you cant just use roles and assign users those roles instead?
|
|
#
¿
Feb 14, 2024 19:58
|
|
|
A lot of this depends on how your AWS org is setup. Are you using identity center or just regular IAM users signing into the console or using keys?
|
|
#
¿
Feb 14, 2024 20:31
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
BaseballPCHiker posted:Once again I am struggling with cross account permissions. So this is from 2+ months ago but I finally figured it out!!!!! When you go cross account from a service like SNS, EventBridge, CloudWatch, etc they dont pass the orgId attribute. So even though my SNS policy on the other side said accept aws:* with my orgID as a condition I couldnt get poo poo to work because those services werent passing that attribute! But if I have them go to lambda as an intermediary with an execution policy then the orgID attribute will get passed. Ugh so frustrating but a hard earned lesson.
|
|
#
¿
Mar 8, 2024 17:27
|
|
|
What would be the best way to add a lifecycle rule to existing buckets in an account that dont already have one? Im basically looking to add a rule to delete aborted multipart uploads in buckets. My first thought was a lambda that would fire and add in the lifecycle rule to buckets, but I dont necessarily know what would trigger that and how I'd put in logic to check for existing lifecycle policies. This is where being lovely with python really backfires for me. Org wide this isnt really a huge issue for us but somehow its caught the attention of my bosses. Nevermind the thousands we waste in orphaned ebs volumes....
|
|
#
¿
Mar 14, 2024 16:18
|
|
|
|
| # ¿ May 22, 2024 07:21 |
|
|
Plank Walker posted:Yeah we had a similar issue with S3 KMS key caching, it's a one liner to add but miss it and oops now you're getting charged for a KMS key retrieval every time you do anything with S3 This has burned my org in the past. Like a lot of things with AWS it feels like it should be the default but isnt. Looking at you HTTPS S3 enforcement.
|
|
#
¿
Apr 5, 2024 16:42
|
|