Best practice for cfn-guard rules for CDK synthesized resources that are wrapped in a CustomResource, e.g. aws-eks.Cluster

0

What is the best practice for standard cfn-guard rules such as eks_endpoint_no_public_access.guard when the resource is being created in a CDK construct that wraps the creation in a Custom Resource and does not directly synthesize the resource specified in the rule?

For example, the rule mentioned is specific to resource type AWS::EKS::Cluster. However, if using aws-cdk-lib/aws_eks.Cluster, the synthesized resource type is Custom::AWSCDK-EKS-Cluster. In this particular case, a rule could be created that satisfies the eks_endpoint_no_public_access.guard rule requirements since the synthesized resource includes an equivalent property.

I'm assuming there is no method to use the standard rule since the resource type and properties do not match in the CDK synthesized template. That being the case, what is the best practice for emulating this rule? Do we simply create our own rule? Name it the identically or differently?

1 Answer
0

You're correct in your assumption that the standard CFN-Guard rules may not directly apply to resources that are wrapped in a Custom Resource by the CDK. The reason for this is that the synthesized resource type in the CloudFormation template may not match the resource type that the CFN-Guard rule is designed to validate.

In the case of the aws-cdk-lib/aws_eks.Cluster construct, the synthesized resource type is Custom::AWSCDK-EKS-Cluster, which is different from the AWS::EKS::Cluster resource type that the eks_endpoint_no_public_access.guard rule is designed to validate.

The best practice in this situation would be to create your own custom CFN-Guard rule that checks the equivalent properties on the synthesized Custom::AWSCDK-EKS-Cluster resource. Here's a general approach you can follow:

  1. Understand the requirements: Thoroughly understand the requirements and logic behind the standard eks_endpoint_no_public_access.guard rule, so that you can translate it to the CDK-specific resource.

  2. Identify the equivalent properties: Examine the properties of the Custom::AWSCDK-EKS-Cluster resource and identify the ones that are equivalent to the properties checked by the eks_endpoint_no_public_access.guard rule.

  3. Create a custom rule: Using the CFN-Guard rule syntax, create a new rule that checks the equivalent properties on the Custom::AWSCDK-EKS-Cluster resource. You can name this rule something similar to the original rule, such as cdk_eks_endpoint_no_public_access.guard, to indicate that it's a custom rule for the CDK-synthesized resource.

  4. Test and validate: Thoroughly test your custom rule to ensure that it properly validates the desired properties and provides the expected behavior.

  5. Apply the custom rule: In your CDK application, apply the custom rule alongside the rest of your CFN-Guard rules.

By following this approach, you can create a custom CFN-Guard rule that emulates the behavior of the standard rule, but is tailored to the specific resource type synthesized by the CDK. This will help ensure that your CDK application adheres to the desired security and compliance requirements.

Remember to keep your custom rules well-documented and maintained, as they may need to be updated if the CDK constructs or the CloudFormation resource definitions change in the future.

AWS
JonQ
answered 6 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions