Compare configuring symmetric encryption (encrypt.key) versus an RSA keystore for a Spring Cloud Config Server. When would you choose each?

encrypt.key = one shared secret, encrypt=decrypt
keyStore.location/.password/.alias/.secret = RSA pair
keytool -genkeypair -keyalg RSA
RSA: public encrypts, private decrypts; strong/salt modes
never commit key/keystore to the repo it protects

basics

~20 s

Symmetric uses a single shared secret in encrypt.key — simple but the same key encrypts and decrypts. An RSA keystore uses a public/private key pair (encrypt.keyStore.*) so encryption and decryption can be separated, giving stronger, more manageable at-rest protection.

solid answer

~40 s

Symmetric: set encrypt.key to a shared secret (usually from an env var). One key both encrypts and decrypts, so anyone/anything with that value can do both. It's trivial to set up and fine for lower-risk or single-team setups. RSA keystore: generate a keypair with keytool into a JKS/PKCS12 file and configure encrypt.keyStore.location, .password, .alias, and .secret. The private key is needed to decrypt; you can distribute or use only the public side for encryption, and the keystore is easier to protect, rotate, and audit than a raw string. RSA also supports salted/strong modes binding ciphertext to a name. Choose symmetric for simplicity/dev; choose RSA when you want asymmetric key separation, stronger crypto, keystore-based custody, or compliance requirements. Never commit either the key or the keystore to the config repo.

code

yaml · 17 lines

yaml

# --- Option A: symmetric (simple) ---
encrypt:
  key: ${ENCRYPT_KEY}          # single shared secret, from env, never in git

# --- Option B: RSA keystore (stronger, manageable) ---
# keytool -genkeypair -alias configkey -keyalg RSA \
#   -keystore server.jks -storepass changeit -keypass changeit \
#   -dname 'CN=Config Server'
encrypt:
  keyStore:
    location: file:/etc/config/server.jks
    password: ${KEYSTORE_PASSWORD}   # opens the keystore
    alias: configkey                 # which key entry to use
    secret: ${KEY_PASSWORD}          # private-key entry password
  rsa:
    strong: true                     # stronger OAEP algorithm
# Choose ONE scheme; do not configure both key and keyStore together.

for a junior

Know symmetric = one shared key; keystore = a key pair; both must be kept secret.

for a middle

Configure each correctly (encrypt.key vs keyStore.location/password/alias/secret) and keep them out of the repo.

for a senior

Weigh key separation, rotation cost, strong/salt modes, and per-app binding when choosing.

for a principal

Fold the choice into org key-management/compliance and know when to abandon {cipher} for a Vault backend.

Spring Cloud Config Server supports two key schemes for encrypting/decrypting {cipher} values.

1) Symmetric key (encrypt.key).

yaml

encrypt:
  key: ${ENCRYPT_KEY}   # a single shared secret string

One key does both encryption and decryption (AES under the hood via spring-security-rsa's TextEncryptor).
Pros: dead simple; one env var; no files. Great for local dev and low-risk internal systems.
Cons: the same secret can both create and reveal ciphertext, so its blast radius is large — anyone holding it decrypts everything. Rotation means re-encrypting all values.
Custody: inject via environment variable (ENCRYPT_KEY) or a secure bootstrap/external source; never put it in the config repo it protects.

2) RSA keystore (encrypt.keyStore.*).

yaml

encrypt:
  keyStore:
    location: classpath:server.jks   # or file:/etc/config/server.jks
    password: ${KEYSTORE_PASSWORD}   # password to open the store
    alias: configkey                 # entry alias
    secret: ${KEY_PASSWORD}          # password of the private key entry

Generate with keytool:

bash

keytool -genkeypair -alias configkey -keyalg RSA \
  -keystore server.jks -storepass changeit -keypass changeit \
  -dname 'CN=Config Server'

Asymmetric: the public key encrypts, the private key decrypts. That separation lets you, in principle, hand out only encryption capability while keeping decryption locked to the server.
Pros: stronger and more manageable key material; standard keystore tooling for storage, backup, rotation, and audit; supports salted / strong modes. Setting encrypt.rsa.strong=true uses a stronger (OAEP) algorithm; encrypt.rsa.salt and encrypting under /encrypt/{name}/{profiles} can bind ciphertext to an app so it can't be reused elsewhere.
Cons: more moving parts (keystore file, two passwords, alias); the file must be deployed and protected.
Custody: ship the keystore outside the config repo; source its passwords from env/secret store.

Precedence / conflicts. If both a symmetric encrypt.key and a keystore are present, configuration is ambiguous — pick one scheme. In practice defining the keystore takes over the crypto; don't mix them.

Requirements. Both rely on JCE (modern JDKs have unlimited strength by default) and spring-security-rsa on the server classpath.

Decision guide.

Symmetric — quickest, dev/test, single small team, low compliance bar.
RSA keystore — production with real secrets, need for algorithm strength, keystore-based key management/rotation, per-app binding, or audit/compliance.
Neither, for very high assurance — delegate to a dedicated secrets backend (e.g., HashiCorp Vault via Spring Cloud Config's Vault backend) instead of {cipher} at all.

Universal gotcha: whichever you choose, the key/keystore is the crown jewel. Losing it makes ciphertext unrecoverable; leaking it exposes every secret. Keep it out of the repo, back it up securely, and plan rotation.

Spring Cloud Config Server supports two key schemes for encrypting/decrypting `{cipher}` values. **1) Symmetric key (`encrypt.key`).** ```yaml encrypt: key: ${ENCRYPT_KEY} # a single shared secret string ``` - **One key does both** encryption and decryption (AES under the hood via `spring-security-rsa`'s `TextEncryptor`). - **Pros:** dead simple; one env var; no files. Great for local dev and low-risk internal systems. - **Cons:** the same secret can both create and reveal ciphertext, so its blast radius is large — anyone holding it decrypts everything. Rotation means re-encrypting all values. - **Custody:** inject via environment variable (`ENCRYPT_KEY`) or a secure `bootstrap`/external source; **never** put it in the config repo it protects. **2) RSA keystore (`encrypt.keyStore.*`).** ```yaml encrypt: keyStore: location: classpath:server.jks # or file:/etc/config/server.jks password: ${KEYSTORE_PASSWORD} # password to open the store alias: configkey # entry alias secret: ${KEY_PASSWORD} # password of the private key entry ``` - Generate with `keytool`: ```bash keytool -genkeypair -alias configkey -keyalg RSA \ -keystore server.jks -storepass changeit -keypass changeit \ -dname 'CN=Config Server' ``` - **Asymmetric:** the **public** key encrypts, the **private** key decrypts. That separation lets you, in principle, hand out only encryption capability while keeping decryption locked to the server. - **Pros:** stronger and more manageable key material; standard keystore tooling for storage, backup, rotation, and audit; supports **salted / strong** modes. Setting `encrypt.rsa.strong=true` uses a stronger (OAEP) algorithm; `encrypt.rsa.salt` and encrypting under `/encrypt/{name}/{profiles}` can bind ciphertext to an app so it can't be reused elsewhere. - **Cons:** more moving parts (keystore file, two passwords, alias); the file must be deployed and protected. - **Custody:** ship the keystore outside the config repo; source its passwords from env/secret store. **Precedence / conflicts.** If both a symmetric `encrypt.key` and a keystore are present, configuration is ambiguous — pick one scheme. In practice defining the keystore takes over the crypto; don't mix them. **Requirements.** Both rely on JCE (modern JDKs have unlimited strength by default) and `spring-security-rsa` on the server classpath. **Decision guide.** - **Symmetric** — quickest, dev/test, single small team, low compliance bar. - **RSA keystore** — production with real secrets, need for algorithm strength, keystore-based key management/rotation, per-app binding, or audit/compliance. - **Neither, for very high assurance** — delegate to a dedicated secrets backend (e.g., HashiCorp Vault via Spring Cloud Config's Vault backend) instead of `{cipher}` at all. **Universal gotcha:** whichever you choose, the key/keystore is the crown jewel. Losing it makes ciphertext unrecoverable; leaking it exposes every secret. Keep it out of the repo, back it up securely, and plan rotation.

With RSA, which half of the keypair does the Config Server need to decrypt {cipher} values at client-request time, and why does that matter?
The private key. Since only the private key decrypts, keystore custody on the server controls who can reveal secrets; the public half only encrypts, so it can be distributed more freely for producing ciphertext.
What operational cost does rotating a symmetric encrypt.key impose that a keystore setup can mitigate?
Rotating the symmetric key means re-encrypting every {cipher} value with the new key. Keystores with multiple aliases and per-app/salted binding make staged rotation and key separation more manageable.

saying these in an interview costs you the question

Claiming symmetric and RSA can be configured together with predictable results
Saying the public RSA key can decrypt values
Storing the encrypt.key or keystore inside the config git repo
Believing RSA keystore removes the need to protect the key material

Compare configuring symmetric encryption (encrypt.key) versus an RSA keystore for a Spring Cloud Config Server. When would you choose each?

answer

basics

solid answer

code

go deeper

context

Compare configuring symmetric encryption (encrypt.key) versus an RSA keystore for a Spring Cloud Config Server. When would you choose each?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~2 min

▾common follow-ups2 questions

▾red flags4 flags

§ context

▾related questions3 questions

▾related topics3 topics

answer

go deeper

context