-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Organization accounts attribute is null for data source: aws_organizations_organization while using child AWS account for AWS provider #18590
Comments
Hi @marshall7m! I tried to reproduce this issue, but was not able to when using the account that owns the organization. Can you provide an organization config that would reproduce the issue? |
Hi @bill-rich! I'm not sure what attributes you're looking for from the organization config, but here's a redacted output from running
I also updated my original post as the problem is only in regards to using the |
Hello, While using child/member AWS account from my organization I have the same issue:
Note that this works if the execution is performed in the organization master account. If this is the expected behaviour, it would be great to update the documentation to highlight it. |
This behaviour is documented in the resource but it does not fit my usecase According to the code, accounts will always be null unless run in the root AWS account due to this if statement
When running inside an account that is a delegated administrator I can run Given this, I think the current behaviour is a bug as it is not expected. As returning null give users a false sense of security that the data has been fetched IMO a better behaviour would be to make the API call and return an access denied error as this can then be worked around by the user. |
…t account This call is allowed in sub-accounts if that account is made delegated administrator for an AWS service
After writing up this pr to remove the check from the code I realised that this could be a breaking change for those who are using this data source to get other attributes such as It would be good to get some feedback from the maintainers on how this should be fixed. IMO to keep backwards compatibility it might be better to move this API call out to a new data-source and deprecate the account field 🤷 I am happy to make the PR if I can get some direction here |
Hi All, I'm running into this same issue and would like to implement a solution. Should we look to modify this same resource or should we look to provide a It really seems like the intent of the |
Given it has been a year now @rnikoopour and there are no dissenting opinions it does seem that a new resource is the way to go. 😄 I think It might just be worth seeing what we can get merged 🤷 |
Just stumbled into this today when writing PermissionSet assignments. I can get around it by explicitly writing every last mapping but would be a nice shortcut to iterate upon. |
You can use the |
Does any data source's ouput has OU id ? |
Not as of 4.63.0 . I have at least not found any in the organizations "package". I tried them all today with
|
Actually i don't think that a new resource is necessary. From what @cob16 wrote this is a bug in the way that the resource does not check if the account is a delegated administrator. So to make this resource backwards compatible adding the additional check would be sufficient. Edit: Just noticed that all API calls that would help check if the account is delegated need the same permissions as the ListAccounts call. So it would be easier to just remove that if conditions as it yields no benefit. If the API call is not allowed then the error should be propagated by the provisioner. So i see the following options:
Edit 2: After thinking about it even more i am pro "new resource". The current datasource combines the DescribeOrganization (and other Describe* calls) and ListAccounts API calls. Splitting this into two new resources one for each API call gives me a better gut feeling. It will eliminate the hazzle of breaking existing code while maintaining a cleaner provisioner. You need to explicitly call the ListAccount API in that way so you should know that the AWS account needs access to it. Edit 3: Sorry for expanding the comment but this is my first time looking into this project. I just noticed that the current provider may violate the contribution guidelines as it does not fit to the API resource described at https://docs.aws.amazon.com/organizations/latest/APIReference/API_Organization.html . Even though the guideline does not mention that a resource has to be 1:1 a representation, it suggests naming data sources according to the data type. Thus an account(s) data source is valid. |
for others caught out by not being able to enumerate a list of org accounts in a delegated admin account, I've ended up doing this to work around it: in CI, before tf is run:
then in tf
it's a bit of pain having to call out to the CLI, hopefully this will get resolved in some fashion soon. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Community Note
Terraform CLI and Terraform AWS Provider Version
Terraform: 0.14.8
AWS-Provider: 3.35.0
Affected Resource(s)
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
Debug Output
Panic Output
Expected Behavior
Actual Behavior
Steps to Reproduce
terraform apply
Important Factoids
UPDATE:
Actual Behavior
Expected Behavior
References
The text was updated successfully, but these errors were encountered: