Valkey Operator requirement for ACL Secret naming convention <instance-name>-acl-secret

Products

• VMware Tanzu Data Suite
• VMware Tanzu for Valkey

Issue/Introduction

When deploying Valkey using the Valkey Operator, the ACL secret name must follow a specific naming convention (as mentioned in this doc): <instance-name>-acl-secret

This can be confusing, especially since the secret name is explicitly configurable via: ValkeySentinel.spec.acl.secret.secretName

If a different secret name is provided, the operator expects the ACL secret to follow the above convention. This may prevent users from applying their own naming standards (for example, avoiding suffixes like -secret if already implied).

Cause

This is by design.

The Valkey Operator enforces this naming convention to:

• Ensure a clear association between each Valkey instance and its corresponding ACL configuration
• Avoid naming collisions across multiple Valkey deployments
• Improve operational clarity, especially in environments with many instances

For example, in a cluster with dozens of Valkey instances and multiple ACL secrets, a standardized naming pattern makes it easier to quickly identify which ACL rules apply to which instance.

Additionally, the operator will attach ownership (ownerReferences) to these secrets, allowing Kubernetes to automatically clean them up when the corresponding ValkeySentinel resource is deleted, preventing orphaned resources.

Resolution

Currently, this behavior is not configurable and users are expected to follow the required naming convention.