Skip to content
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

Open
hannes-ucsc opened this issue Dec 17, 2024 · 10 comments
Open

Critical SecurityHub finding Config.1 #6766

hannes-ucsc opened this issue Dec 17, 2024 · 10 comments
Assignees
Labels
+ [priority] High bug [type] A defect preventing use of the system as specified compliance [subject] Information and software security infra [subject] Project infrastructure like CI/CD, build and deployment scripts orange [process] Done by the Azul team spike:1 [process] Spike estimate of one point

Comments

@hannes-ucsc
Copy link
Member

CleanShot 2024-12-16 at 22 22 01@2x

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 states

If you delete this service-linked role, you can use this same process to create the role again.

so 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.

@hannes-ucsc hannes-ucsc added the orange [process] Done by the Azul team label Dec 17, 2024
@achave11-ucsc achave11-ucsc added the spike:1 [process] Spike estimate of one point label Dec 17, 2024
@achave11-ucsc achave11-ucsc self-assigned this Dec 17, 2024
@achave11-ucsc achave11-ucsc added bug [type] A defect preventing use of the system as specified infra [subject] Project infrastructure like CI/CD, build and deployment scripts compliance [subject] Information and software security + [priority] High labels Dec 17, 2024
@achave11-ucsc
Copy link
Member

Every account's check for left-over service-linked role for AWS Config.

devhca-dev
anvildevanvildev
anvilprodanvilprod
prodprod

@hannes-ucsc
Copy link
Member Author

hannes-ucsc commented Dec 20, 2024

To summarize the above: dev and prod have a left-over service-linked role (SLR).

Next steps are

  • Delete the left-over SLR from dev
  • Wait a week, delete the left-over SLR from prod
  • Prepare PR to remove custom role and (re)create SLR, and associate any custom policies to the SLR instead

@hannes-ucsc hannes-ucsc removed their assignment Dec 20, 2024
@achave11-ucsc
Copy link
Member

Assignee to complete first step above.

@achave11-ucsc achave11-ucsc self-assigned this Dec 20, 2024
@achave11-ucsc
Copy link
Member

achave11-ucsc commented Dec 20, 2024

Attempting to complete the first step above was unsuccessful due to the following,
Screenshot 2024-12-20 at 3 54 13 PM

It seems this (SLR) is still being used by Config, which prevents us from deleting it.

And via the AWS CLI

❯ aws iam delete-role --role-name AWSServiceRoleForConfig

An error occurred (UnmodifiableEntity) when calling the DeleteRole operation: Cannot perform the operation on the protected role 'AWSServiceRoleForConfig' - this role is only modifiable by AWS

@hannes-ucsc
Copy link
Member Author

hannes-ucsc commented Jan 6, 2025

There were a bunch of recorders in other regions that had to be deleted, first. After that, the deletion succeeded:

CleanShot 2025-01-06 at 11 17 19@2x

@achave11-ucsc
Copy link
Member

achave11-ucsc commented Jan 7, 2025

Deletion succeeded:
DeleteOK

  • Wait a week, delete the left-over SLR from prod

Complete.

@achave11-ucsc achave11-ucsc removed their assignment Jan 7, 2025
@hannes-ucsc
Copy link
Member Author

There was supposed to be a waiting period of one week between the deletion in dev and prod.

@achave11-ucsc
Copy link
Member

That was my mistake.
Thankfully, it'd been almost two years since the deleted SLR was last used in prod.

@hannes-ucsc
Copy link
Member Author

Thankfully, it'd been almost two years since the deleted SLR was last used in prod.

That's not sufficient evidence that the deletion wouldn't have caused an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
+ [priority] High bug [type] A defect preventing use of the system as specified compliance [subject] Information and software security infra [subject] Project infrastructure like CI/CD, build and deployment scripts orange [process] Done by the Azul team spike:1 [process] Spike estimate of one point
Projects
None yet
Development

No branches or pull requests

3 participants