Cross-Account Role Trust and EKS Credential Blast Radius
A SaaS provider runs 60 AWS accounts and has just enabled a CIEM tool. It reports 12 cross-account roles whose trust policies allow a partner's AWS account ID; one of those roles has AdministratorAccess and is used by a nightly batch job. Separately, 200 IAM users still have long-lived access keys, and 14 EKS workloads inherit the node instance role, which allows s3:* across all buckets. An SCP restricts deployments to three regions but does not restrict IAM. The partner insists its integration will break if the trust policy changes, and the batch job has no documented owner. Audit evidence requires least privilege and no long-lived keys for human access. The security team has 10 business days before an external audit.
1. How do you evaluate and remediate the 12 cross-account roles in 10 days without breaking the partner integration?
Read the worked answer
I would inventory each role's trust policy, permissions, last-used data, and actual API activity from CloudTrail. The key questions are: which external principal assumes the role, is there an external ID or source restriction, what can the role do, and has it been used recently? IAM Access Analyzer external-access findings help confirm which roles are truly reachable outside the organization.
The AdministratorAccess role is first. If the partner needs it, I would replace it with a scoped role limited to the specific APIs and resources, require an external ID and, where possible, a source account or VPC endpoint condition, and shorten session duration. I would test in a non-production account with the partner. The nightly batch job needs an owner; if none is found, I would disable the role after confirming no recent successful use and provide a break-glass path.
For audit evidence, document each change, the validation test, and any time-bound exception with compensating controls. I would not rely on the regional SCP as an IAM control, because it does not constrain trust policies or permissions.
2. The 14 EKS workloads use the node instance role with s3:*. What is the risk today, and what is the remediation path?
Read the worked answer
The risk is credential reuse and blast radius. Any pod on those nodes may reach the instance metadata service and obtain the node role credentials, then use s3:* against any bucket the role can access. IMDSv2 and hop limiting reduce some SSRF paths but do not solve over-privileged pods. I would check CloudTrail for unusual S3 access by the node role and inspect whether any pod has already queried IMDS.
Remediation is to move workloads to EKS Pod Identity or IRSA with per-workload service accounts and scoped S3 permissions. The node role should retain only what the node needs, such as CNI and image pulls. Roll out namespace by namespace, verify application access, then remove S3 permissions from the node role. Add admission controls to block privileged pods, hostPath mounts, and hostNetwork where not required.
Because audit is imminent, I would prioritize the workloads that touch sensitive buckets and document the migration plan for the rest. Rotating node role credentials after scoping is important, because old credentials may have been exposed.
3. What is your plan for the 200 long-lived IAM user access keys before the audit?
Read the worked answer
I would classify the keys into human and machine use. Human access should move to federation with SSO and MFA, then keys should be disabled. Machine access should move to IAM roles, instance profiles, EKS workload identities, or a secrets manager with rotation. A credential report and last-used data let me separate unused keys from active ones.
In 10 days, I would disable keys unused for more than 90 days, rotate active keys with owner notification, and set a hard disable date for human keys. For machine keys that cannot migrate before the audit, I would require a documented exception with a rotation date and compensating controls, such as IP restriction and least-privilege policies. I would avoid mass deletion without owner confirmation because that can cause outages.
The audit narrative should show a real reduction plan, not just a snapshot. Evidence includes before-and-after key counts, federation adoption, rotation records, and exception approvals.