feat: TLS for Keystone ↔ Memcached (placeholder, blocked on memcached-operator TLS support)

[berendt]

Why

Keystone ↔ Memcached is currently plaintext TCP on 11211. Verified:

• operators/keystone/internal/controller/reconcile_config.go:84-89 writes cache.memcache_servers = <name>:11211 and memcache.servers = …, with no TLS parameters.
• CacheSpec in operators/keystone/api/v1alpha1/keystone_types.go has no TLS fields.
• deploy/flux-system/infrastructure/memcached.yaml is replicas: 3, image: memcached:1.6 only — no listener TLS.

This is a placeholder. Implementation is blocked until the upstream C5C3/memcached-operator CRD gains a spec.tls block — see the linked operator issue.

Rough scope (to elaborate, once unblocked)

• Add spec.cache.tls to the Keystone CRD (enabled, caBundleSecretRef, optional clientCertSecretRef for mTLS).
• Reconciler:
  • issue/consume cert-manager Certificate for the API pod's memcached client when mTLS is enabled,
  • mount cert/key/ca, render keystone.conf [cache] with tls_enabled = True, tls_cafile = …, tls_certfile = …, tls_keyfile = …,
  • or pass via connect_args once dogpile.cache.pymemcache options are confirmed in the deployed Keystone version.
• Enable tls.enabled: true (eventually clientAuth: required for mTLS) on the Memcached CR in deploy/flux-system/infrastructure/memcached.yaml.
• E2E: chainsaw test under tests/e2e/keystone/cache-tls/ asserting handshake on 11211 and that plaintext is refused once mTLS is required.

Blocked on

• C5C3/memcached-operator: TLS listener support in the Memcached CR.

Tracking

Sibling issues track MariaDB-mTLS and OpenBao mTLS.