CloudFront Controller - Ability to reference K8s secrets key/value in custom headers

[trc-ikeskin]

Is your feature request related to a problem?

As describe in the AWS documentation it is good practice to secure access to Application Load Balancer origins using secret HTTP header KV-pair on both the CloudFront origin request and ALB listener rule to make backend access exclusive to the configured CloudFront Distributions.

Such secret values are typically stored in AWS Secrets Manager and synced to the cluster in the form of K8s secrets using tools like the External Secrets Operator for further use in other K8s resources.

Describe the solution you'd like

Make it possible to declare a secret reference (name and key) for both the headerName and headerValue keys of the items in distributionConfig.origins.items[].customHeaders.items[] of the Distribution custom resource.

Example:

distributionConfig:
  origins:
        items:
          - customHeaders:
              items:
                - headerName:
                    fromSecretName: this-is-a-k8s-secret-name
                    fromSecretKey: this-is-a-key-in-above-k8s-secret
                  headerValue:
                    fromSecretName: this-is-a-k8s-secret-name
                    fromSecretKey: this-is-a-key-in-above-k8s-secret
# ...

Similar options exist e.g. for the RDS Controllers DBInstance resource where the master password can be referenced using masterUserPassword.name, masterUserPassword.key and
masterUserPassword.namespace.

Describe alternatives you've considered

• Do lookup in Helm templates but not really feasible due to ArgoCD limitations Helm lookup Function Support argoproj/argo-cd#5202
• Using SOPS and related mechanisms with tools like https://github.com/jkroepke/helm-secrets, https://piggysec.com/, etc. which add a lot of complexity especially in cross-account deployment setups

[github-actions]

Hello @trc-ikeskin 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[knottnt]

Hi @trc-ikeskin, while we do support referencing k8s Secrets for some fields we've so far limited implementing this feature to fields where the associated AWS Service treats the field as secret. For example, in the case RDS's masterUserPassword RDS doesn't return the masterUserPassword at all when describing a DBCluster or DBInstance. We've been hesitant to implement this feature where the field is returned in plaintext when reading the resource. Which appears to be the case looking the GetDistribution API.

For Cloudfront we do support VPC Origins which may work as an alternative.
Restrict access with VPC origins

[trc-ikeskin]

Hi @knottnt, I am not really sure I understand the reasoning behind that decision.

Since we have to use shared subnets from a centralized network account (VPC is not in the same account as the CF distribution) VPC origins are not an option for us.

In cases like this you would then be effectively left with the very cumbersome alternatives I mentioned above or pushing secret values to your GitOps repo…