[New]: ALB Mutual Authentication

[dallasanta]

Description

Given that AWS has launched a new functionality to enable Mutual Authentication on ALBs (https://aws.amazon.com/blogs/aws/mutual-authentication-for-application-load-balancer-to-reliably-verify-certificate-based-client-identities/)

And aws-sdk-go already supports that
And CloudFormation has already implemented that through the following resources:

• [New] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-truststore.html
• [New] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-truststorerevocation.html
• [Updated] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-listener.html

Then AWS provider should have its own implementation

Requested Resource(s) and/or Data Source(s)

• aws_lb_trust_store
• aws_lb_trust_store_revocation

Potential Terraform Configuration

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[matt-mercer]

Hi @dallasanta I've created a PR for this with a minimal implementation : #34584

so far just allowing the creation of a trust_store resource/data source and binding to a load balancer,
there are some challenges around the trust_store as the s3 object information used to create the trust store is not retained in describe-trust-store .. so I'm envisaging there might be a case to manage the trust_store outside of terraform and bind it to an ALB using the data source ..

plan to follow on with a PR for for the revocation or add in to the depending on how long the review / merge cycle is.

[dallasanta]

thanks @matt-mercer for the implementation! I think it would be helpful to have the s3 config in the state file as I can see it's a valid use case to modify the trust store. I'm afraid I'm not a reviewer on this project so I don't think I can help getting it over the line.

[matt-mercer]

@dallasanta totally agree .. I just don't know there's an easy way to achieve this, I've seen some closed issues that look 'similar' to what it would be good to do ... on the flip side , it's probably OK, if a modify-trust-store action fires on apply that re-deploys the same CA cert .. just noisy / slightly scary when you're not expecting a change.

Though, for my own use-case I'm intially thinking I'll manage the trust-store itself outside of terraform and just use the data-source to bind to the load balancer .. rather than get the churn, until this can be addressed

[matt-mercer]

@dallasanta actually it works fine .. the ca_certificates_bundle_s3_bucket / ca_certificates_bundle_s3_key are automatically saved into state .. so repeat applys don't trigger change .. think you'd just get an initial one post import ..

[github-actions]

This functionality has been released in v5.30.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.