-
Notifications
You must be signed in to change notification settings - Fork 2
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
Critical SecurityHub finding Config.1 #6766
Comments
To summarize the above: Next steps are
|
Assignee to complete first step above. |
There was supposed to be a waiting period of one week between the deletion in |
That was my mistake. |
That's not sufficient evidence that the deletion wouldn't have caused an issue. |
AWS Config is configured and functioning but the control fires anyway since we use a custom IAM role instead of a service-linked role as required by Config.1. We could set the
includeConfigServiceLinkedRoleCheck
parameter on the control, to disable that role-check part of the control but I see no reason. I do see a correctly named service-linked for AWS Config role one of our AWS accounts. It seems to be a left-over from manually enabling AWS Config. Our TF Config makes no mention of it.We should delete the custom IAM role, and create a service-linked role instead, using the appropriate TF config. The custom role is associated with a managed policy and a custom one. The same should be the case for the service-linked role. The
AssumeRole
part of the custom role is obsolete. Service-linked roles have that part hard-wired.Instead of importing the existing but unused service-linked role left-over in
prod
, and any other account for that matter, we should simply delete the role. AWS documentation statesso we should be able to simply delete the role and recreate it when the updated TF config is applied.
Spike to check every account for a left-over service-linked role for AWS Config.
The text was updated successfully, but these errors were encountered: