-
Notifications
You must be signed in to change notification settings - Fork 271
Description
Is your feature request related to a problem?:
Yes, this feature request is related to a problem regarding the consistency of referencing dependent AWS resources within the CacheCluster CRD for the ACK for ElastiCache controller.
Currently, the CacheCluster resource allows referencing a notification SNS Topic in two ways: by providing the direct AWS ARN (notificationTopicArn) [1] or by providing a Kubernetes object reference (notificationTopicRef)[2] to an SNS Topic object managed by the SNS ACK Controller.
This dual-reference capability for SNS Topics is highly beneficial as it allows a seamless GitOps workflow where dependencies are expressed as references between Kubernetes objects.
However, this flexibility is not extended EC2 Security Groups. The CacheCluster CRD currently only allows referencing Security Groups by their explicit AWS ID (securityGroupIDs), as seen here [3]:
This lack of a Kubernetes object reference option for Security Groups means that if a user is managing their EC2 Security Groups using the EC2 ACK controller, they cannot simply reference these objects by name in their CacheCluster manifest. They are forced to obtain the AWS-generated Security Group ID after the SecurityGroup CR is reconciled and then manually or programmatically inject that ID into the CacheCluster manifest. This disrupts the declarative GitOps flow that is possible with SNS Topic references.
Describe the solution you'd like:
I would like the CacheCluster CRD in the ElastiCache ACK controller to be enhanced to include an option for referencing EC2 Security Groups using a Kubernetes object reference, similar to how SNS Topics can be referenced.
This would involve adding a new field (e.g., securityGroupRefs) to the CacheClusterSpec that accepts an array of references to ec2.services.k8s.aws/v1alpha1 SecurityGroup objects by their name and namespace within the Kubernetes cluster.
The controller should then be able to resolve these Kubernetes object references to the corresponding AWS Security Group IDs and associate them with the ElastiCache cluster.
Describe alternatives you've considered:
The primary alternative is the current method, which requires referencing Security Groups only by their AWS ID (securityGroupIDs). As described in the problem section, this necessitates automation to retrieve the AWS ID after the SecurityGroup is created by the EC2 ACK controller and then updating the CacheCluster manifest.