Contractor and Machine Identity in a 40-Account Organization
A software company uses Okta as its identity provider and AWS IAM Identity Center for 40 AWS accounts. It has 600 employees and 120 contractors. Contractors currently use IAM users with long-lived access keys because a legacy build tool cannot assume roles. A recent penetration test found an access key in a public repository that had s3:GetObject on a production bucket. Thirty-eight IAM users still have console passwords, and 12 of them have no MFA. The break-glass administrator role is shared by five platform engineers and uses a static access key stored in a team password manager. The company plans to move the legacy tool to Kubernetes next quarter but must reduce identity risk now. The CISO asks for a target architecture and a 30-day remediation plan that does not break contractors' daily work. Audit findings must be closed before the SOC 2 Type II window opens in eight weeks.
1. Propose a target identity architecture for employees, contractors, and machine identities. Explain how it eliminates long-lived IAM users without breaking the legacy build tool.
Read the worked answer
Separate human and machine identity. For humans, use Okta as the single IdP and IAM Identity Center permission sets mapped to account-level roles. Put employees and contractors in different Okta groups with different session durations, approval requirements, and permission-set assignments. Enforce phishing-resistant MFA for all console access. Contractors should get time-bound accounts and just-in-time elevation rather than standing production roles.
For machine identities, eliminate long-lived keys. Workloads in AWS should use IAM roles: EKS Pod Identity or IRSA for Kubernetes, Lambda execution roles for serverless, and instance profiles for EC2. For the legacy build tool that cannot assume roles, deploy IAM Roles Anywhere with a trusted certificate authority, or front the tool with a small credential broker that assumes a scoped role. The broker should issue short-lived credentials and log every issuance. Add an SCP denying iam:CreateUser and iam:CreateAccessKey in all accounts except a controlled break-glass account. This closes the finding without waiting for the Kubernetes migration.
2. The penetration test found a production S3 read key in a public repository. Outline the immediate response and the least-privilege redesign for that workload.
Read the worked answer
Immediate response: disable the IAM user and deactivate the access key; do not delete logs. Search CloudTrail for all API calls made with that key, including source IP, user agent, and accessed object prefixes. Determine whether any objects were downloaded or listed. Rotate any secrets the workload could reach, check for new IAM users or role changes, and notify according to the incident-response policy. Preserve the repository commit history as evidence.
Redesign: replace the IAM user with a role assumed by the build workload. Scope the role to the exact bucket and prefix, not s3:* or *. Use a bucket policy that allows only the role ARN and, where possible, restricts access to a VPC endpoint. Add conditions for aws:SourceVpce or aws:PrincipalOrgID. Run IAM Access Analyzer and review unused permissions after two weeks. Put secret scanning in the CI pipeline and block pushes containing AWS key patterns. The goal is not just removing this key but removing the ability to create another one.
3. Design governance for the break-glass role: who can use it, how it is protected, and how you would test it.
Read the worked answer
Break-glass should be a last-resort path, not a shared admin role. Put it in a dedicated security account with a distinct role that has no standing access to production. Require two-person approval for production use, FIDO2 MFA, and a short maximum session. Do not store a static access key in a password manager; if a physical credential is needed, use a hardware token in a sealed safe with checkout logging. Grant the role only to named senior engineers and rotate eligibility quarterly.
Alert on every AssumeRole and every policy change to the break-glass role. Log the session to a separate immutable account and require a post-use review within 24 hours. Test quarterly: one tabletop exercise and one controlled assume in a non-production account. Verify that approval, alerting, and session termination work. After any real use, rotate credentials, review all actions, and document why normal access failed. The test evidence should show both successful legitimate use and a denied use without approval.