|
I've never been part of a compliance satisfaction scheme that has required me to describe the exact mechanism by which users are provisioned and deprovisioned, typically the requirements I see are that the processes must be documented, the documented process must be followed, and the deprovisioning must be able to materialize an access revocation within some extremely generous timeframe. The actual mechanism for it is trivial, IAM has an API or you can even click in the web interface if you don't like it. Plenty of compliant and publicly traded technical organizations run on checklists and email. My personal preference is gitops iac, but it doesn't really matter. The users that exist and their authorizations are fully described by the main branch of a git repository at all times, changes to these definitions are peer reviewed and each link to a concrete instance of a business process (JIRA ticket) which also links to other events from the HRIS. Then you just need to prove that: No changes to the git repository were made without peer review. No changes to the users were made except by the git repository's approved mechanisms. No changes were made that were not linked to a JIRA ticket, and every JIRA ticket for this process always linked to your HR bullshit. You sill get to check "yes" on whatever stupid questionnaire you received from the bored secops team in the fortune 500. If they have any further questions you can just give them your SOC 3 report.
|
#
¿
Nov 29, 2022 18:45
|
|
|
|
| # ¿ May 15, 2024 21:15 |
|
|
Arzakon posted:and not the lambda script you invented to mimic SSO but for IAM users. Just to clarify, this would be a thing that rotates IAM keys, not a thing that mimics SSO. I'd also probably just use yours https://github.com/aws-samples/aws-iam-access-key-auto-rotation instead of inventing it again. 
|
|
#
¿
Nov 29, 2022 19:09
|
|
|
keeping them adjacent in the same repo is usually better in my experience, although i usually name the folder terraform/ instead of infra/
|
|
#
¿
Mar 1, 2023 01:21
|
|
|
route53 is really good, i totally understand using it everywhere. maybe not for external records i guess. theyre not very price competitive
|
|
#
¿
Apr 27, 2023 06:58
|
|
|
iirc if you go s3 -> sns you only ever get 1 sns topic per notification config, something to be aware of in case you might need more destinations later you can mix queues and topics though to my recollection so it's not a big deal
|
|
#
¿
Jun 13, 2023 20:30
|
|
|
just uploading a zip puts less requirements on the uploader which is good because uploaders tend to change over time and janitoring an uploader is all toil for no benefit
|
|
#
¿
Jun 15, 2023 17:06
|
|
|
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 edit to include docs link: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html highly recommend everyone who touches AWS at work read the full iam documentation, especially this part, whenever they have a moment
|
|
#
¿
Sep 19, 2023 17:47
|
|
|
Unless you're going out of your way to build as much stuff as possible to demonstrate how full stack it is, I would probably use beanstalk.
|
|
#
¿
Jan 8, 2024 23:05
|
|
|
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
|
|
|
the documentation for this is here https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint.html
|
|
#
¿
Feb 29, 2024 17:24
|
|
|
|
| # ¿ May 15, 2024 21:15 |
|
|
I was completely ready to say mean things about it but it looks fine actually. It's not that different from many take-home technical interviews I've been presented with. Some of the tool choices are bad, is the worst thing I can muster.
|
|
#
¿
Mar 8, 2024 02:26
|
|