E
Ethical Chipmunk
Currently, Harness supports direct OIDC authentication but doesn't support cross account STS Assume Role with OIDC credentials.
Expected Flow:
Harness SaaS -> OIDC -> Central AWS IAM Role - STS AssumeROle -> Target AWS Account Role -> (AWS service/eks, ecr, etc)
This capability is important for enterprise managing 100s of AWS accounts, allowing centralized OIDC federation, a central security kill switch, simplified account onboarding and reduced maintenance without configuring an OIDC provider in every target account.
  1. Blast radius: SaaS vendors compromised sometimes and when that happens we aggressive have to address. If it happens here and immediate actions are necessary there is one OIDC provider that has to be shutdown versus 100s of them across our org.
  2. Preferred deployment pattern: The assume role pattern is a well-worn deployment pattern and defendable to multiple stakeholders: risk, cyber, app owners, etc.
  3. Governance: less to inventory, track, attribute ownership, explain and defend in our high compliance and risk averse environment
The enhancement should work with native Harness CI/CD steps, including Build and Push to ECR, without requiring custom authentication scripts or static AWS credentials.