[CFT] Add Federated Identity template for Elastic Workload Identity (WII)

[jeniawhite]

Summary of your changes

Adds deploy/cloudformation/federated-identity-wii-aws.yml, the WII (Elastic Workload Identity Issuer) counterpart of federated-identity-aws.yml. Same role and grants, but the trust is an OIDC provider for the WII issuer of the customer's organization and region, and the role can only be assumed by one deployment (ECH) or project (Serverless):

<issuer-host>/orgs/<org-id>:aud = sts.amazonaws.com
<issuer-host>/orgs/<org-id>:sub = <deployment|project>:<id>

Inputs: ElasticOrganizationId, ElasticResourceType, ElasticResourceId, ElasticCloudProvider, ElasticCloudRegion, ElasticCloudEnvironment. CreateOidcProvider (default true) exists because IAM allows one OIDC provider per URL per account; a second stack for the same org and region has to reuse the existing one.

The template is also added to scripts/publish_cft.sh.

Why not trust all WII endpoints

WII issues tokens with a per-region iss, so in production that is 63 issuers. IAM does not allow wildcards in Federated principals, so all 63 provider ARNs would have to be listed in the trust policy (~7.5k chars, default quota 2048, max 8192). Adding the sub condition needs one statement per issuer, ~29k chars, which cannot fit at all. A deployment or project lives in one region anyway, so one issuer per stack is both sufficient and the smallest trust.

Why no loop

Fn::ForEach can create N providers from a list parameter, but it cannot produce list items, so there is no way to feed a variable number of provider ARNs into the role's trust policy. It also needs the AWS::LanguageExtensions transform, and with one issuer per stack there is nothing to loop over.

Related Issues

• https://github.com/elastic/kibana-feature-flags/pull/207 — FF lock to not promote changes to customers and limit to internal users for all environments

Checklist

• cfn-lint passes; grants diffed against federated-identity-aws.yml
• Deployed against QA for the hosted and serverless flows

[mergify]

This pull request does not have a backport label. Could you fix it @jeniawhite? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[seanrathier]

WII issues tokens with a per-region iss, so in production there are 63 issuers. IAM does not allow wildcards in Federated principals, so all 63 provider ARNs would have to be listed in the trust policy (~7.5k chars; default quota is 2048, max is 8192). Adding the sub condition requires one statement per issuer, pushing it to ~29k chars — which can't fit at all. Since a deployment or project lives in one region anyway, one issuer per stack is both sufficient and the smallest possible trust surface.

If I'm reading your ask correctly: is single-deployment trust good enough for the MVP, or do we need to solve the multi-deployment case first?

This means a RoleArn cannot be shared between, say, a production ECH deployment and a staging ECH deployment.

Sharing a RoleArn across deployments or projects wasn't something I'd accounted for in the upgrade CFT key flow, but it actually creates a real problem. Imagine: we verify the key and it doesn't match because the staging deployment has an extra integration, so we upgrade the CFT. Now the production deployment's trust is broken. We're in a catch-22 loop.

IMO, single-deployment trust is the right path for MVP, especially once you factor in the upgrade CFT flow. Is that aligned with what you're thinking?

[bhapas]

Should this have DeletionPolicy: Retain.

IAM allows one provider per URL per account. The first stack owns that provider; later stacks set CreateOidcProvider=false and reference it by ARN. Deleting the first stack removes the provider and breaks every reused stack.

• Stack A creates the IAM OIDC provider (one per URL per account).
• Stack B sets CreateOidcProvider=false and points its role at the same provider ARN by convention.
• You delete stack A. AWS deletes resources stack A owns, including the OIDC provider (unless DeletionPolicy: Retain).
• Stack B still has CreateOidcProvider=false. It does not recreate the provider. Its role’s trust policy still names an ARN that no longer exists. AssumeRoleWithWebIdentity fails.

[bhapas]

Suggested change

	Description: Kibana component ID of the deployment, or the Serverless project ID.
	Description: Elastic deployment ID of the deployment, or the Serverless project ID.

[bhapas]

ElasticWorkloadIdentity- prefix is 26 characters; IAM role names max out at 64.

Maybe Long stack names will fail create.

[bhapas]

https://github.com/elastic/cloud/blob/master/scala-services/domain-core/src/main/scala/co/elastic/cloud/domain/ids/OrganizationId.scala#L34 states that it should be [A-Za-z0-9]{1,32}