Integrating Kong Helm chart with a Secret Manager

Kubernetes
1

I’m using the official Helm chart to deploy Kong to GKE. The chart expects sensitive values (such as certificates/private keys, database credentials, session tokens, etc.) to be put into Kubernetes Secrets, which should be then referenced in the Helm values.yaml file.

E.g.

# Inject specified secrets as a volume in Kong Container at path /etc/secrets/{secret-name}/
# This can be used to override default SSL certificates.
# Be aware that the secret name will be used verbatim, and that certain types
# of punctuation (e.g. `.`) can cause issues.
# Example configuration
# secretVolumes:
# - kong-proxy-tls
# - kong-admin-tls
secretVolumes:
  - kong-cluster-cert
  - kong-endpoints-cert

or

  database: "postgres"
  pg_host: "postgresql.kong"
  pg_port: 5432
  pg_database: "kong"
  pg_user: "kong"
  pg_password:
    valueFrom:
      secretKeyRef:
        name: postgresql-creds
        key: postgresql-password

Due to my organisation’s security limitations, I’m not allowed to use Kubernetes Secrets and should use a secret manager instead, like GCP Secrets Manager or Hashicorp Vault. Does Kong Helm chart support reading sensitive values from such manager, rather than from Kubernetes Secrets? How to best achieve that?

2

Your best option is the beta secrets management feature in 2.8. Currently this is only available for kong.conf settings; support for configuration managed via the API is forthcoming: Get Started with Secrets Management - v2.8.x | Kong Docs

Helm itself doesn’t read values from the cluster environment, it’s just writing instructions (the Secret references) for Kubernetes to read and bind those values later.

The secret manager integration documentation indicates that they expose secrets as files or by including a library in the application code:

The filesystem approach won’t work since Kong generally doesn’t support reading values off the filesystem for configuration. Kong’s secrets management is the library integration approach.

1 Like
3

Thank you, this looks like something I was looking for!

I gave Secrets Management a try and it’s working well for passing string values. I was able to replace PostgreSQL configuration with:

env:
  database: "postgres"
  pg_host: "postgresql.kong"
  pg_port: 5432
  pg_database: "kong"
  pg_user: "kong"
  pg_password: "{vault://hcv/postgresql-password}"

However I’m not sure how to best handle TLS certificates using this approach. Kong expects certificates/private keys to be mounted into the container with the paths configured in environment variables like this:

env:
  cluster_cert: "/etc/secrets/kong-cluster-cert/tls.crt"
  cluster_cert_key: "/etc/secrets/kong-cluster-cert/tls.key"

It doesn’t look achievable to store certificates/private keys as strings in Vault and reference them like this:

env:
  cluster_cert: "{vault://hcv/cluster-cert}"
  cluster_cert_key: "{vault://hcv/cluster-cert-key}"

Is there any solution to that?

4

Not as-is. It’d be good feedback for a post in Discussions · Kong/kong · GitHub on the initial implementation, to alert them that there’s a use case that’s not quite covered due to those settings’ requirement for a filename.

That said, the Vault injector should work well here, since it does create file mounts as far as I can tell.