-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
route53: CrossAccountZoneDelegationRecord broken in opt-in regions #23081
Labels
@aws-cdk/aws-route53
Related to Amazon Route 53
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
Comments
rix0rrr
added a commit
that referenced
this issue
Nov 25, 2022
This is a revert of #22370. The fix proposed there solved one very specific (but rare) use case, in exchange for breaking common use cases. - *It fixed the case of*: AWS service authors using their own global service principal in the delegation role, with both source and target account opted into the region. - *It broke the case of*: all teams that didn't have both accounts opted into the region. The second case is much more common, so revert to the old behavior. Since the regional behavior might still be useful to *some* people somewhere, it has been relegated to a context key, `@aws-cdk/aws-route53:useRegionalStsEndpoint`, instead. It can be configured, but is not advertised as 99.9% of users will not need this behavior. Since both STS and Route53 are global and regular customers cannot usefully use Service Principals in this particular trust policy anyway, there is no impact to regular customers. Fixes #23081.
mergify bot
pushed a commit
that referenced
this issue
Nov 28, 2022
This is a revert of #22370. The fix proposed there solved one very specific (but rare) use case, in exchange for breaking common use cases. - *It fixed the case of*: AWS service authors using their own global service principal in the delegation role, with both source and target account opted into the region. - *It broke the case of*: all teams that didn't have both accounts opted into the region. The second case is much more common, so revert to the old behavior. Since the regional behavior might still be useful to *some* people somewhere, it has been relegated to a context key, `@aws-cdk/aws-route53:useRegionalStsEndpoint`, instead. It can be configured, but is not advertised as 99.9% of users will not need this behavior. Since both STS and Route53 are global and regular customers cannot usefully use Service Principals in this particular trust policy anyway, there is no impact to regular customers. Fixes #23081. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
brennanho
pushed a commit
to brennanho/aws-cdk
that referenced
this issue
Dec 9, 2022
…23082) This is a revert of aws#22370. The fix proposed there solved one very specific (but rare) use case, in exchange for breaking common use cases. - *It fixed the case of*: AWS service authors using their own global service principal in the delegation role, with both source and target account opted into the region. - *It broke the case of*: all teams that didn't have both accounts opted into the region. The second case is much more common, so revert to the old behavior. Since the regional behavior might still be useful to *some* people somewhere, it has been relegated to a context key, `@aws-cdk/aws-route53:useRegionalStsEndpoint`, instead. It can be configured, but is not advertised as 99.9% of users will not need this behavior. Since both STS and Route53 are global and regular customers cannot usefully use Service Principals in this particular trust policy anyway, there is no impact to regular customers. Fixes aws#23081. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
brennanho
pushed a commit
to brennanho/aws-cdk
that referenced
this issue
Jan 20, 2023
…23082) This is a revert of aws#22370. The fix proposed there solved one very specific (but rare) use case, in exchange for breaking common use cases. - *It fixed the case of*: AWS service authors using their own global service principal in the delegation role, with both source and target account opted into the region. - *It broke the case of*: all teams that didn't have both accounts opted into the region. The second case is much more common, so revert to the old behavior. Since the regional behavior might still be useful to *some* people somewhere, it has been relegated to a context key, `@aws-cdk/aws-route53:useRegionalStsEndpoint`, instead. It can be configured, but is not advertised as 99.9% of users will not need this behavior. Since both STS and Route53 are global and regular customers cannot usefully use Service Principals in this particular trust policy anyway, there is no impact to regular customers. Fixes aws#23081. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
brennanho
pushed a commit
to brennanho/aws-cdk
that referenced
this issue
Feb 22, 2023
…23082) This is a revert of aws#22370. The fix proposed there solved one very specific (but rare) use case, in exchange for breaking common use cases. - *It fixed the case of*: AWS service authors using their own global service principal in the delegation role, with both source and target account opted into the region. - *It broke the case of*: all teams that didn't have both accounts opted into the region. The second case is much more common, so revert to the old behavior. Since the regional behavior might still be useful to *some* people somewhere, it has been relegated to a context key, `@aws-cdk/aws-route53:useRegionalStsEndpoint`, instead. It can be configured, but is not advertised as 99.9% of users will not need this behavior. Since both STS and Route53 are global and regular customers cannot usefully use Service Principals in this particular trust policy anyway, there is no impact to regular customers. Fixes aws#23081. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-route53
Related to Amazon Route 53
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
Describe the bug
The changes introduced in #22370 (in response to #22022) seem to have broken some internal Amazon customers.
It seems Route53 is a global (partitional) service so there is only one endpoint.
Original motivation for the change
The original motivation for the change seems to have been:
The response to this was to change the endpoints to regional, but that may have been a premature fix.
The original reporter was an AWS employee, capable of creating their own Service Principals, and they were using Service Principals in the trust policy. External customers would be using an Organization ID or Account number here.
We need to revert this.
The text was updated successfully, but these errors were encountered: