You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The data-collection/deploy/deploy-data-collection.yaml template contains a parameter that is used in multiple resources.
Such as prefixing resource names, in IAM Role Paths, and to construct the MultiAccountRoleName parameter passed in nested stacks.
Issue:
There are use cases where customers may want to use an existing role and pass that Role Name through the MultiAccountRoleName parameter. However, this can cause complications/issues since that parameter is prefixed with the ResourcePrefix: MultiAccountRoleName: !Sub "${ResourcePrefix}${MultiAccountRoleName}"
Attempts to get around this issue were to provide an empty string for ResourcePrefix however this causes failures since IAM role paths are constructed using the ResourcePrefix
Path:
Fn::Sub: /${ResourcePrefix}/ # resolves to // with empty string which is invalid
Workaround:
The only way around this issue if you want to provide your own Role is to split the role name between ResourcePrefix and MultiAccountRoleName.
For example: With a Role named: MyCustomIAMRole
ResourcePrefix: My MultiAccountRoleName: CustomIAMRole
So that when it combines it becomes the correct full role name while also providing a value for ResourcePrefix
ResourcePrefix: MultiAccountRoleName: !Sub "${ResourcePrefix}${MultiAccountRoleName}" # Resolves to MyCustomIAMRole
This is clearly not ideal as now other resources will be prefixed with My
Fix:
Update so that either ResourcePrefix is used conditionally in IAM Role Paths or MultiAccountRoleName is used without the ResourcePrefix when constructing/passing it as a parameter (e.g. MultiAccountRoleName: !Ref MultiAccountRoleName)
The text was updated successfully, but these errors were encountered:
Allenkkim
changed the title
Support optional ResourcePrefix parameter in
Support optional ResourcePrefix parameter in deploy-data-collection.yaml
Oct 16, 2024
Summary:
The data-collection/deploy/deploy-data-collection.yaml
template contains a parameter that is used in multiple resources.
Such as prefixing resource names, in IAM Role Paths, and to construct the MultiAccountRoleName parameter passed in nested stacks.
Issue:
There are use cases where customers may want to use an existing role and pass that Role Name through the MultiAccountRoleName parameter. However, this can cause complications/issues since that parameter is prefixed with the ResourcePrefix:
MultiAccountRoleName: !Sub "${ResourcePrefix}${MultiAccountRoleName}"
Attempts to get around this issue were to provide an empty string
for ResourcePrefix however this causes failures since IAM role paths are constructed using the ResourcePrefix
Workaround:
The only way around this issue if you want to provide your own Role is to split the role name between ResourcePrefix and MultiAccountRoleName.
For example: With a Role named: MyCustomIAMRole
ResourcePrefix: My
MultiAccountRoleName: CustomIAMRole
So that when it combines it becomes the correct full role name while also providing a value for ResourcePrefix
ResourcePrefix:
MultiAccountRoleName: !Sub "${ResourcePrefix}${MultiAccountRoleName}"
# Resolves to MyCustomIAMRoleThis is clearly not ideal as now other resources will be prefixed with
My
Fix:
Update so that either ResourcePrefix is used conditionally in IAM Role Paths or MultiAccountRoleName is used without the ResourcePrefix when constructing/passing it as a parameter (e.g.
MultiAccountRoleName: !Ref MultiAccountRoleName
)The text was updated successfully, but these errors were encountered: