-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(rds): support certificate autority certificate #26883
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, thank you. Got just a couple requests.
* | ||
* @default - rds-ca-2019 | ||
*/ | ||
readonly caCertificateIdentifier?: CertificateIdentifier; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
readonly caCertificateIdentifier?: CertificateIdentifier; | |
readonly caCertificate?: CertificateIdentifier; |
Can you drop the Identifier
everywhere please. It's not really relevant to the user intent.
Also in the docstring, e.g. The the CA certificate used for this DB instance.
/** | ||
* The CA identifier of the DB instance | ||
*/ | ||
export enum CertificateIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export enum CertificateIdentifier { | |
export enum CaCertificate { |
/** | ||
* The CA identifier of the DB instance | ||
*/ | ||
export enum CertificateIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you turn the enum into an enum-like class instead, with the ability to create a CaCertificate from a custom string: new CaCertificate('future-identifier')
class CaCertificate {
static public RDS_CA_2019() { return new CaCertificate('rds-ca-2019') }
public constructor(identifier: string) { }
}
Reason is that this property strikes me as one that will likely have new values added in future.
With an enum-like class, users can always use whatever value they want and don't need to wait for us to add the new value and/or can use new values without having to upgrade the CDK version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more in favor of enums vs enum-like classes. How often do CaCertificate
change that ability to add new values is needed?
With an enum-like class, users can always use whatever value they want and don't need to wait for us to add the new value and/or can use new values without having to upgrade the CDK version.
Does this mean enum-like classes will be used all across other parts of CDK instead of enums?
@mrgrain @lpizzinidev I'm warming up to enum-like class approach 😄 . Would this approach be better than getters & setters? In the code we'd use export class CaCertificate {
/**
* rds-ca-2019 certificate authority
*/
public static readonly RDS_CA_2019 = CaCertificate.of('rds-ca-2019');
/**
* rds-ca-ecc384-g1 certificate authority
*/
public static readonly RDS_CA_ECC384_G1 = CaCertificate.of('rds-ca-ecc384-g1');
/**
* rds-ca-rsa2048-g1 certificate authority
*/
public static readonly RDS_CA_RDS2048_G1 = CaCertificate.of('rds-ca-rsa2048-g1');
/**
* rds-ca-rsa4096-g1 certificate authority
*/
public static readonly RDS_CA_RDS4096_G1 = CaCertificate.of('rds-ca-rsa4096-g1');
/**
* Custom certificate identifier
* @param custom certificate authority identifier
*/
public static of(identifier: string) { return new CaCertificate(identifier); }
/**
*
* @param certificate authority identifier
*/
private constructor(public readonly identifier: string) { }
} |
/** | ||
* The CA identifier of the DB instance | ||
*/ | ||
export enum CertificateIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more in favor of enums vs enum-like classes. How often do CaCertificate
change that ability to add new values is needed?
With an enum-like class, users can always use whatever value they want and don't need to wait for us to add the new value and/or can use new values without having to upgrade the CDK version.
Does this mean enum-like classes will be used all across other parts of CDK instead of enums?
@robertd Thanks for the review! Yes this is exactly what I had in mind. Apologies for not conveying this in my review. I think in general it's the better pattern because it enables us to easily extend features in future. E.g. what if (theoretically) you could upload your own CA Certificate in future. It's more strongly typed and unlike enums can be extended on by userland code. In the wider TS community, there's some talk at the moment about how enums are bad in general. So yes, we probably should use enum-like classes everywhere instead. In practice, it might more relevant for some situations than others. I picked it up here, because historically with certificates there has ALWAYS be a newer one. Whereas other choices often are fundamentally more limited. |
@mrgrain Yep, makes total sense in this use case. If @lpizzinidev can change enum-like class to use
|
@lpizzinidev is on the top of the game with this PR with updating it to the latest changes we discussed. LGTM. 👍 |
@robertd Thanks for the feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last question regarding the default.
* For Aurora DB engines: | ||
* @see https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL-certificate-rotation.html | ||
* | ||
* @default - CaCertificate.RDS_CA_2019 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This default is unexpected and seems like a potentially breaking change to me. Can you explain or remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to create an instance from the console, it suggests rds-ca-2019
as default (this is the reason for the @default
).
Anyway, looking at the CFN documentation, it does not specify any default, so I guess I should remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It probably doesn't change much, but I think we want to end up in this case:
"If you don't select a certificate authority, RDS chooses one for you."
* @default - CaCertificate.RDS_CA_2019 | |
* @default - RDS will choose a certificate authority |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defaulting to ‘rds-ca-2019’ will definitely be a breaking change. We also have a year before this becomes an issue. :)… until then… hopefully, anyone creating new instances/clusters will move to the newer CAs ahead of time anyway. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It probably doesn't change much, but I think we want to end up in this case: "If you don't select a certificate authority, RDS chooses one for you."
AWS will pick the CA flavored soup of the day lol… I like it :)
@@ -865,6 +920,7 @@ abstract class DatabaseInstanceNew extends DatabaseInstanceBase implements IData | |||
domain: this.domainId, | |||
domainIamRoleName: this.domainRole?.roleName, | |||
networkType: props.networkType, | |||
caCertificateIdentifier: props.caCertificate ? props.caCertificate.identifier : CaCertificate.RDS_CA_2019.identifier, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default question, see above.
caCertificateIdentifier: props.caCertificate ? props.caCertificate.identifier : CaCertificate.RDS_CA_2019.identifier, | |
caCertificateIdentifier: props.caCertificate ? props.caCertificate.identifier : undefined, |
Btw, we also could implement a toString()
method on CaCertificate
. This is works as well though.
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Many thanks @lpizzinidev 🚀
static .of() usually refers to a known given, like an enum. Why would the constructor be private and then publish the of( method to be a constructor wrapper, it's a bit inverse right now. If you want a custom CA i'd think: I think I'd still prefer to go with the enums for consistency. Feels more light weight than having the instances be instantiated in properties of a static class.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
But using it would still be typed to new CaCertificate(CertificateIdentifier.RDS_CA_2019) and instantiate an object anyway. I don't think the practical memory savings from not having all variations pre-instantiated are worth the worse UX.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
@Mergifyio requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
do we need another implementation to support this for |
Exposes the
caCertificate
property for an RDS instance to allow specifying a custom CA identifier using theCaCertificate
class.Usage:
Closes #26865.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license