skip to content

By default the Config Server decrypts {cipher} values before responding. How do you make the client decrypt instead, and why might you want that?

level: seniorimportance: should knowfreq 30%

answer

  1. spring.cloud.config.server.encrypt.enabled=false -> pass-through
  2. server-side (default) = plaintext on the wire, no client key
  3. client-side = client holds key, decrypts locally
  4. tradeoff: key custody vs plaintext exposure
  5. flag lives on the SERVER

basics

~20 s

Set spring.cloud.config.server.encrypt.enabled=false on the server so it passes {cipher} values through untouched. Each client must then hold the key and decrypt them itself. You'd do this so plaintext secrets never leave the client boundary or transit the network.

solid answer

~40 s

Server-side decryption is the default: the Config Server holds the key and returns plaintext, so responses over the wire contain the actual secrets. To move the trust boundary to the client, set spring.cloud.config.server.encrypt.enabled=false. Now the server relays {cipher} values verbatim, and each client app — which must have the encryption key configured (e.g. encrypt.key) and the crypto libraries — decrypts them locally as it binds its Environment. Benefits: plaintext secrets never traverse the network or sit in Config Server memory/logs, reducing exposure if the server or transport is compromised. Costs: every client needs the key distributed and protected, which multiplies key-custody surface and complicates rotation. It's a tradeoff between centralizing the key (server-side) versus never exposing plaintext beyond the client (client-side).

code

yaml · 15 lines
yaml
# --- Config SERVER: turn OFF server-side decryption ---
spring:
  cloud:
    config:
      server:
        encrypt:
          enabled: false   # relay {cipher} values untouched to clients
encrypt:
  key: ${ENCRYPT_KEY}      # server may still know the key (e.g. to run /encrypt)

# --- Config CLIENT: must now hold the key to decrypt locally ---
# (client application config)
encrypt:
  key: ${ENCRYPT_KEY}      # same key the values were encrypted with
# The client receives '{cipher}...' and decrypts it while binding its Environment.

go deeper

for a junior

Know the default is server decrypts; the client normally needs no key.

for a middle

Set spring.cloud.config.server.encrypt.enabled=false and give clients the key to move decryption to the client.

for a senior

Articulate the threat-model tradeoff: plaintext-on-the-wire vs key-distribution surface.

for a principal

Decide per environment based on trust in the server/transport and key-management capacity; document rotation implications of each model.

**Two decryption models.** `{cipher}` values can be decrypted in one of two places, controlled by `spring.cloud.config.server.encrypt.enabled` (default `true`) on the **server**: **A) Server-side decryption (default, `encrypt.enabled=true`).** - The Config Server holds the key, decrypts `{cipher}` values, and sends **plaintext** in the HTTP response. - Clients need **no key** and no crypto config — simplest to operate. - Downside: secrets exist as plaintext (a) in the server's memory while assembling the response, (b) on the network (mitigated by TLS), and potentially (c) in server logs/actuator dumps if misconfigured. The Config Server becomes a high-value target. **B) Client-side decryption (`spring.cloud.config.server.encrypt.enabled=false`).** - The server **does not** decrypt; it passes the `{cipher}...` values through **unchanged**. - Each **client** must have the key configured (`encrypt.key` or a keystore) and the crypto on its classpath. As the client processes the config it fetched, it decrypts `{cipher}` values while binding its `Environment` (historically during the bootstrap phase). - Benefit: **plaintext never leaves the client's own JVM** — not over the wire, not in the Config Server. If the Config Server or the network is compromised, only ciphertext is exposed. - Cost: the key must be **distributed to every client** and protected there; more copies = larger custody surface and harder rotation. You also lose the 'clients need nothing' simplicity. **Where the flag lives.** `spring.cloud.config.server.encrypt.enabled` is a **server** property (note `.server.`). Setting it `false` is what enables the client-side model. There is no separate client toggle to 'turn on' decryption beyond giving the client the key and crypto libs. **Requirements for the client model.** Clients must include the config client + `spring-security-rsa` crypto and be given the same key material the values were encrypted with. Missing key -> client sees literal `{cipher}...` strings or fails. **Gotchas.** - Mixing expectations: if the server still decrypts (default) but you also gave clients a key, the clients just receive plaintext and never use their key — harmless but confusing. - With client-side decryption, an unconfigured client silently receives ciphertext; guard against booting with a `{cipher}...` literal as a password. - TLS is still recommended even in the client model to protect the rest of the (non-secret) config and integrity. **When to choose.** - **Server-side:** most setups; you trust the Config Server and TLS, and want minimal client config. - **Client-side:** stricter threat models where the Config Server or transport is not fully trusted, or where policy forbids plaintext secrets leaving the consuming service's boundary. Accept the heavier key-distribution burden.

  • On which application does spring.cloud.config.server.encrypt.enabled belong, and what breaks if you set it on the client by mistake?
    It belongs on the Config Server (note '.server.'). Set on the client it has no effect on the server, so the server keeps decrypting and the flag is silently ignored.
  • In the client-side model, what happens if a client lacks the key or crypto libraries?
    The client cannot decrypt and ends up with the literal '{cipher}...' string as the property value (or a binding failure), so it must fail fast rather than boot with a bogus secret.

saying these in an interview costs you the question

  • Thinking there's a client-side 'enable decryption' flag rather than just giving the client the key
  • Believing default responses contain ciphertext (they contain plaintext)
  • Claiming client-side decryption removes all need for TLS

context

resolving links…