Stale GitHub thumbprints

[pmoghaddam]

Stale GitHub thumbprints

[moltar]

Fix in the spirit of #18 - removing the entire ThumbprintList list in favour of automatic updates.

See: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_iam.OpenIdConnectProvider.html#thumbprints

const provider = new GithubActionsIdentityProvider(this, 'GitHubProvider')

/**
 * Removes hard-coded `ThumbprintList` list, because this list is volatile, and the
 * parent construct is not being updated.
 *
 * @see https://github.com/aripalo/aws-cdk-github-oidc/issues/24
 * @see https://github.com/aripalo/aws-cdk-github-oidc/pull/18
 */
Aspects.of(provider).add({
  visit(node) {
    if (node instanceof CfnResource && node.node.id === 'Default') {
      node.addPropertyDeletionOverride('ThumbprintList')
    }
  },
})

[moltar]

Good news!

Automatic notice from AWS:

Hello,

We are sending this notification because you have configured a GitHub OpenID Connect (OIDC) identity provider (IdP) in your AWS account. GitHub uses a cross-signed TLS server certificate for GitHub’s OIDC servers which can have two intermediate certificates. Each of these intermediate certificates has a unique thumbprint. If you configured the GitHub IdP in your account using only one thumbprint, you may have encountered “Error: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint” when attempting to access AWS resources using GitHub as the identity provider. This would occur when the certificate thumbprint configured in AWS does not match the one presented by the GitHub server.

No action is required from you.

Starting July 6, 2023, AWS began securing communication with GitHub’s OIDC identity provider (IdP) using our library of trusted root Certificate Authorities instead of using a certificate thumbprint to verify the IdP’s server certificate. This approach ensures that your GitHub OIDC configuration behaves correctly without disruption during future certificate rotations and changes. With this new validation approach in place, your legacy thumbprint(s) will remain in your configuration but will no longer be needed for validation purposes.

[douglasnaphas]

The CDK Construct OpenIdConnectProvider downloads the thumbprint based on the issuer URL, if the thumbprint is not supplied to it as a prop.

I wonder whether it would be better to omit any specific thumbprint from this Construct’s source, and let the OpenIdConnectProvider figure out the right thumbprint based on the issuer URL.

Then we would not have to periodically update the thumbprint in this Construct.

[bryan-queryai]

For anyone using Python you can override these values in the CFN output like this:

        # create the github identity provider
        self.github_identity_provider = GithubActionsIdentityProvider(
            scope=scope, id=f"{stage}-github-provider"
        )

        # get the cloudformation custom resource
        cfn_github_identity_provider: CustomResource = (
            self.github_identity_provider.node.default_child
        )

        # for each child of the cfn resource add the thumbprint list override
        for child in cfn_github_identity_provider.node.children:
            if isinstance(child, CfnResource):
                child.add_override(
                    "Properties.ThumbprintList",
                    [
                        "1c58a3a8518e8759bf075b76b750d4f2df264fcd",
                        "6938fd4d98bab03faadb97b34396831e3780aea1",
                    ],
                )

[bilalq]

There was a past PR that would've addressed this: #18

[dne]

Automatic updates in Python, based on @moltar's and @bryan-queryai's snippets:

provider = GithubActionsIdentityProvider(self, "provider")
for child in provider.node.default_child.node.children:
    if isinstance(child, CfnResource):
        child.add_property_deletion_override("ThumbprintList")

[aripalo]

First of all, apologies for not handling this issue as it came out. I've been on summer vacation since June 22nd, and though I have not been completely offline / off-the-grid, I haven't really worked with any code, used GitHub, or read any code/work related emails, etc – hence I missed this issue.

Secondly, thanks for reporting the issue and for the workarounds posted to this issue (I've heard from multiple people that those have helped during the time this issue persisted.

Third, luckily AWS handled this whole ordeal in their end 🎉 That being said, I think I should just remove the existing thumbprint definitions from this construct. Originally I knew that they are optional and IAM "can figure them out", but I saw them as an extra layer of security – on hindsight – they should've been optional even with this construct and leave the addition (and updates) of those for the end-user. But as said above (and as I've also now seen in my AWS accounts), AWS is now handling the verification using trusted root CA.