Quiz Report Card: Secrets and Config Maps

Date: 2026-03-09 | Qwen 3.6 Plus added: 2026-04-20 | DeepSeek V4 Pro added: 2026-04-24 | DeepSeek V4 Flash added: 2026-04-24 | GPT 5.5 added: 2026-04-25 | Kimi K2.6 added: 2026-04-26 | Qwen3.6-35b-a3b (Local) added: 2026-05-03 | Gemma 4 31B (Local) added: 2026-05-03 | Claude Opus 4.8 added: 2026-05-31 Question: What are the differences between Kubernetes secret objects and Kubernetes configmap objects from a security perspective, why shouldn’t a user just use configmaps for storing secret information?

Reference Answer

Key security differences between Secrets and ConfigMaps:

Both stored in etcd — can be encrypted at rest, but isn’t by default. Importantly, the encryption-at-rest mechanism can encrypt ConfigMaps too (via EncryptionConfiguration). The difference is that Secrets are the typical target for encryption configuration.
Encryption at rest protects against direct etcd access (API or disk) but does NOT protect against users with Kubernetes API access — the API server decrypts secrets before returning them to the user.
Base64 encoding on secrets is NOT a security measure — it exists for binary data compatibility, not confidentiality.
RBAC: ConfigMaps are included in standard roles like view; Secrets are not. This is a critical operational difference — anyone with the view ClusterRole can read ConfigMaps but not Secrets.
Kubernetes makes efforts to not log secrets — the API server avoids including secret data in audit logs and other output. ConfigMaps do not receive the same protection.
Intent/semantic signal — using Secrets conveys that the information should be treated as sensitive. Backup software, tooling, dashboards, and operators will treat Secrets with more care than ConfigMaps.

Scoring Criteria

Both in etcd: Recognition that both are stored the same way
Encryption at rest: Correctly describe what it protects and its limits (API server still decrypts)
ConfigMap encryption possible: The encryption mechanism CAN encrypt configmaps too
Base64 is not security: Must explicitly note this
RBAC view role difference: ConfigMaps in view, Secrets are not
Logging protection: Kubernetes avoids logging secret data
Intent/semantic signal: Using secrets tells the ecosystem the data is sensitive
Accuracy: No incorrect claims

Results Summary

Model	Score	Both in etcd	CM Encryption	Base64 Caveat	View Role	Logging	Intent	Errors
anthropic/claude-opus-4.7	6/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong
openai/gpt-5.4	8/10	Yes	Acknowledged	Yes	No (close)	Yes	Yes	None
anthropic/claude-sonnet-4.6	7/10	Yes	No	Yes	No	Brief	Yes	CM encryption wrong
deepseek/deepseek-v3.2	6/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong
minimax/minimax-m2.5	6/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong, verbose
google/gemini-3-flash-preview	6/10	Yes	No (strongest wrong claim)	Yes	No	Yes	Yes	CM “never” encrypted, compliance overclaims
minimax/minimax-m2.7	8/10	Yes	No	Yes	No	Yes	Yes	None
qwen/qwen3.6-plus	6/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong, some overclaims
deepseek/deepseek-v4-pro	9/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong
deepseek/deepseek-v4-flash	7/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong
moonshotai/kimi-k2.6	7/10	Yes	No	Yes	No	Yes	Yes	Implies encryption at rest is default
openai/gpt-5.5	9/10	Yes	Yes	Yes	No	Yes	Yes	None
qwen/qwen3.6-35b-a3b (LOCAL)	7/10	Yes	Yes	Partial	Incorrectly claims ConfigMaps can’t be encrypted at rest
anthropic/claude-opus-4.8	6/10	Yes	No	Yes	No	Yes	Yes	CM encryption wrong
google/gemma-4-31b (LOCAL)	7/10	Yes	No	Yes	CM encryption wrong	Incorrectly claims ConfigMaps can’t be encrypted at rest

Detailed Analysis

anthropic/claude-opus-4.7 — 6/10

Strengths:

Correctly identifies both stored in etcd
Mentions EncryptionConfiguration for encryption at rest
Correctly notes base64 is encoding, not encryption
Mentions tmpfs for secrets volumes

Weaknesses:

Claims ConfigMaps don’t benefit from encryption at rest — factually incorrect. EncryptionConfiguration supports ConfigMaps explicitly.
Missing the view ClusterRole distinction (includes ConfigMaps, excludes Secrets)
Missing API server decryption limitation

Comparison vs Opus 4.6 (6): Same score. Same gaps persist — ConfigMap encryption eligibility, view ClusterRole, API decryption limit.

Notable: The Anthropic family blind spot on ConfigMap encryption continues. All three Anthropic models (Opus 4.7, Opus 4.6, Sonnet) miss this, while only GPT 5.4 correctly acknowledges it.

openai/gpt-5.4 — 8/10

Strengths:

Only model to acknowledge ConfigMap encryption is possible: “While ConfigMaps may also be covered depending on cluster encryption configuration” — this is the key nuance from the scoring notes
Excellent “reality check” section: “A Kubernetes Secret is not a vault. Anyone who can read the Secret via the API… may be able to retrieve the secret value” — correctly conveys that encryption at rest doesn’t protect API users
Base64 is encoding, not encryption — clearly stated
Strong intent/semantic signal coverage: “Secrets are the mechanism Kubernetes and its ecosystem expect for sensitive data”
Logging/redaction: tools redact secret values, configmaps more likely to leak
Good coverage of tooling, CI/CD, GitOps, dashboards
Measured, accurate tone throughout

Weaknesses:

Does not specifically mention the view ClusterRole including ConfigMaps but not Secrets (says “administrators often allow broader access to ConfigMaps” which is close)
Could have mentioned tmpfs mounting

Notable: The only model to correctly note that ConfigMaps can also be encrypted at rest. The “reality check” section is the best handling of the API-server-decrypts-before-returning point across all models.

anthropic/claude-sonnet-4.6 — 7/10

Strengths:

Base64 not encryption — explicit section with decode example
Good comparison table covering key differences
Encryption at rest covered with EncryptionConfiguration example
tmpfs memory storage mentioned
Good “Important Caveats” section acknowledging secrets aren’t truly secure by default
Final summary captures the intent point: “signal to operators/tooling that the data is non-sensitive”

Weaknesses:

Table states ConfigMaps are “Unencrypted” in etcd — implies they cannot be encrypted, which is incorrect per the scoring notes
Does not mention the view ClusterRole RBAC difference
Audit trail/logging differences mentioned only briefly
Does not explicitly state that the API server decrypts before returning to the user

Notable: Good balance of depth and practical examples (RBAC role, EncryptionConfiguration). The base64 decode example is the most practical demonstration across all models.

deepseek/deepseek-v3.2 — 6/10

Strengths:

Base64 not encryption clearly stated
Good coverage of audit log exposure
“Secrets are redacted (show only size/hash)” — correct
RBAC differences noted
Practical YAML examples
External secret manager mention

Weaknesses:

Claims “ConfigMap data is always plaintext in etcd” — incorrect; ConfigMaps can be encrypted via EncryptionConfiguration
Does not mention the view ClusterRole RBAC difference
Does not mention API server decrypts before returning to user
Memory handling section is vague (“implementation-dependent”)

Notable: Solid coverage of the practical differences but the “always plaintext” claim about ConfigMaps is the same error most models make.

minimax/minimax-m2.5 — 6/10

Strengths:

Comprehensive coverage with detailed comparison table
Base64 not security — stated in best-practice checklist
Good ecosystem/tooling coverage (CSI drivers, External Secrets Operator, Vault)
Built-in secret types (TLS, dockerconfigjson, etc.) — useful additional context
tmpfs mentioned
Logging/UI masking covered

Weaknesses:

Claims “no built-in at-rest encryption option” for ConfigMaps — incorrect per scoring notes
Does not mention the view ClusterRole RBAC difference
Does not mention API server decrypts before returning to user
Very verbose — the answer is significantly longer than needed, with some sections (immutability, SPIFFE/mTLS) adding little to the security comparison
Compliance claims (PCI-DSS, SOC2) are unsupported assertions

Notable: The most comprehensive answer in terms of volume, but length doesn’t equal accuracy. The ConfigMap encryption error and missing key RBAC point limit the score.

google/gemini-3-flash-preview — 6/10

Strengths:

Base64 not encryption — clearly stated with “shoulder surfing” angle
Good tmpfs explanation with forensic footprint concept
Logging: “Kubernetes components are designed to avoid printing the contents of Secrets in system logs”
Ecosystem integration coverage
Encryption at rest covered with external KMS providers

Weaknesses:

Strongest wrong claim: “Data in ConfigMaps is never encrypted at rest by the Kubernetes native encryption provider” — this is explicitly incorrect. The EncryptionConfiguration can encrypt ConfigMaps.
Does not mention the view ClusterRole RBAC difference
Does not mention API server decrypts before returning to user
Compliance audit claims (PCI-DSS, SOC2, HIPAA) are unsupported — PSS levels and Secrets don’t directly map to specific compliance frameworks
“Zero Encryption” summary claim reinforces the error

Notable negative: The “never encrypted at rest” claim is the strongest misstatement across all models. The scoring notes specifically highlight that ConfigMaps CAN be encrypted using the same mechanism as Secrets.

minimax/minimax-m2.7 — 8/10

Strengths:

Correctly explains both stored in etcd
Mentions encryption at rest
Addresses base64 is NOT security
tmpfs for Secrets vs regular files
RBAC differences
Audit logging
Excellent external secret manager recommendations (ESO, Sealed Secrets, Vault)

Weaknesses:

Doesn’t mention the view ClusterRole includes ConfigMaps but not Secrets (practically important)
Implies ConfigMaps can’t be encrypted at rest when they actually can via EncryptionConfiguration

Notable: Matches GPT 5.4 at 8/10 — tied for best on this question. Strong practical understanding but misses the same nuances as most models.

qwen/qwen3.6-plus — 6/10

Strengths:

Correctly identifies both stored in etcd
Base64 not encryption — clearly stated: “not encryption… signals intent and triggers security workflows”
Good audit logging coverage: “Values automatically redacted/masked in audit logs by default”
Strong intent/semantic signal: ecosystem integration with policy engines, scanners, secret managers
Good practical section on etcd encryption at rest
Mentions RBAC differences: secrets “tightly scoped by default”

Weaknesses:

Claims ConfigMaps have “Never targeted by default encryption configs” for etcd encryption — incorrect. EncryptionConfiguration can encrypt ConfigMaps using the same mechanism as Secrets.
Overclaims on file permissions: States secrets default to 0400 or 0600 while ConfigMaps default to 0644 — the actual default permissions for both volume-mounted types are configurable and the difference is less stark than claimed
Claims ConfigMaps lack “No Built-in Rotation or Lifecycle Controls” compared to Secrets — Secrets don’t have fundamentally different lifecycle controls; both are standard API objects
Does not mention the view ClusterRole RBAC difference
Does not explicitly state API server decrypts before returning to user
Compliance claims (PCI-DSS, SOC 2, ISO 27001, HIPAA) are unsupported assertions

Notable: Strong on intent/signal and audit logging, but repeats the common ConfigMap encryption error and makes several overclaims about the differences. The compliance framework references are the same type of unsupported claim that Gemini 3 Flash and MiniMax M2.5 made.

deepseek/deepseek-v4-pro — 9/10

Strengths:

Thorough and security-focused response
Explains encryption-at-rest for Secrets with EncryptionConfiguration
RBAC separation: correctly notes ConfigMaps are in standard view role
tmpfs mounting for Secrets volumes
Auditing differences between Secrets and ConfigMaps
Mentions 1MB Secret size limit
Good coverage of external secret manager integration

Weaknesses:

Still claims ConfigMaps cannot be encrypted at rest — factually incorrect per EncryptionConfiguration documentation

Notable: Takes the top score on this question at 9/10, beating GPT 5.4 and MiniMax M2.7’s previous best of 8/10. The most comprehensive answer overall — strong on RBAC, auditing, tmpfs, and practical implications. The only gap is the ConfigMap encryption misconception shared by nearly every model except GPT 5.4. A major improvement over DeepSeek V3.2 (6/10).

deepseek/deepseek-v4-flash — 7/10

Strengths:

Correctly identifies both stored in etcd
Base64 is encoding, not encryption — clearly stated
Good coverage of audit logging differences
Mentions tmpfs for secrets volumes
Intent/semantic signal well covered
Reasonable RBAC differences noted

Weaknesses:

Incorrectly claims ConfigMaps can’t be encrypted via EncryptionConfiguration — the same misconception shared by nearly every model except GPT 5.4. EncryptionConfiguration can encrypt ConfigMaps using the same mechanism as Secrets.
Does not mention the view ClusterRole RBAC difference
Does not explicitly state API server decrypts before returning to user

Notable: Scores between V4 Pro (9/10) and V3.2 (6/10). Good practical coverage of the security differences but repeats the persistent ConfigMap encryption misconception. The entire DeepSeek family shares this gap (V3.2: 6, V4 Pro: 9, V4 Flash: 7).

openai/gpt-5.5 — 9/10

Strengths:

Correctly acknowledges ConfigMap encryption is possible: “ConfigMaps can also be encrypted at rest if explicitly configured, but they often are not” — joins GPT 5.4 as one of the only models to get this right
Excellent base64 caveat with practical decode example
Strong RBAC coverage: correctly notes ConfigMaps are “commonly readable by more users” and Secrets are a separate resource for RBAC purposes
Good tooling/UI behaviour coverage: kubectl describe redacts secret values but shows ConfigMap values plainly
Strong logging/leakage section: ConfigMaps more likely to end up in “support tickets, Slack messages, CI logs, Git repositories”
Correctly notes tmpfs memory-backed storage for secret volumes
Good intent/semantic signal: security tools, admission controllers, audit policies target Secrets specifically
Accurate “reality check”: “Kubernetes Secrets are not magically secure” and “not encrypted merely because they are called Secrets”

Weaknesses:

Does not specifically mention the view ClusterRole including ConfigMaps but not Secrets (discusses the concept of broader ConfigMap access but not the specific role)
Could emphasise “not encrypted by default” more explicitly upfront — the table says “Not necessarily; depends on cluster config” for both, which is accurate but understated

Notable: Ties with DeepSeek V4 Pro at 9/10, taking the joint top score. The most comprehensive and well-structured answer across all models — six distinct sections explaining why ConfigMaps should not store secrets. Like GPT 5.4, correctly handles the ConfigMap encryption nuance that nearly every other model gets wrong. A major improvement over GPT 5.4 (8/10) in terms of depth and practical examples.

moonshotai/kimi-k2.6 — 7/10

Strengths:

Correctly identifies both stored in etcd
Base64 not encryption — clearly stated
Good coverage of audit logging differences
Intent/semantic signal well covered
Mentions tmpfs for secrets volumes

Weaknesses:

Incorrectly implies encryption at rest is enabled by default — encryption at rest requires explicit configuration via EncryptionConfiguration and is not on by default
Does not correctly note that ConfigMaps can also be encrypted via EncryptionConfiguration
Missing the view ClusterRole RBAC difference (ConfigMaps included, Secrets are not)

Notable: Scores 7/10, matching Sonnet and DeepSeek V4 Flash. Good overall coverage of the security differences but the encryption-at-rest misunderstanding limits the score. The implication that encryption is default could give administrators false confidence.

qwen/qwen3.6-35b-a3b (LOCAL) — 7/10

Strengths:

Correctly identifies both stored in etcd
Good on base64 not being encryption — clearly explained
Encryption at rest for Secrets covered correctly
Audit log masking for secrets mentioned
Good intent/semantic signal coverage

Weaknesses:

Factual error: claims ConfigMaps cannot be encrypted at rest — they can, via the same EncryptionConfiguration mechanism as Secrets. This is the most common factual error across all models on this question.
Misses the critical view ClusterRole distinction — ConfigMaps are included in the standard view ClusterRole while Secrets are excluded. This is a practically important RBAC difference that no model has yet correctly identified.
Does not explicitly state that the API server decrypts before returning data to the user

Notable: Matches Sonnet, DeepSeek V4 Flash, and Kimi K2.6 at 7/10. Repeats the same ConfigMap encryption misconception shared by nearly every model except GPT 5.4 and GPT 5.5. The errors are the same type of mistakes that larger cloud models make — this appears to be a gap in Kubernetes documentation coverage rather than a model size issue.

google/gemma-4-31b (LOCAL) — 7/10

Strengths:

Correctly identifies both Secrets and ConfigMaps are stored in etcd
Base64 not encryption — clearly stated with good explanation
Good coverage of audit logging differences — Secrets values are masked in logs, ConfigMaps are not
Intent/semantic signal well covered — Secrets signal to tooling that data is sensitive
Mentions RBAC differences between Secrets and ConfigMaps at a general level

Weaknesses:

Incorrectly claims ConfigMaps cannot be encrypted at rest — they can via the same EncryptionConfiguration mechanism as Secrets. This is the same misconception shared by the majority of models.
Missing the view ClusterRole distinction — ConfigMaps are in the standard view ClusterRole while Secrets are excluded. No model has yet identified this.
Does not explicitly state that the API server decrypts before returning data to the user

Notable: Matches Qwen-35b, Sonnet, DeepSeek V4 Flash, and Kimi K2.6 at 7/10. The ConfigMap encryption misconception is the universal gap across nearly all models — only GPT 5.4 and GPT 5.5 correctly acknowledge that ConfigMaps can be encrypted at rest. No fabricated information — errors are omissions and the one shared misconception.

anthropic/claude-opus-4.8 — 6/10

Strengths:

Correctly identifies both stored in etcd
Base64 is encoding, not encryption — clearly stated
Good coverage of audit logging differences
Intent/semantic signal well covered
Mentions tmpfs for secrets volumes

Weaknesses:

Factual error: claims ConfigMaps can’t be encrypted at rest — they can, via the same EncryptionConfiguration mechanism as Secrets. This is the persistent Anthropic family blindspot on this question.
Missing the view ClusterRole distinction (ConfigMaps included, Secrets excluded)
Missing Kubernetes log redaction point

Comparison vs Opus 4.7 (6): Same score. The ConfigMap encryption misconception persists across all four Anthropic models (Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 4.6) — none have caught this nuance.

Notable: Matches Opus 4.7 and Opus 4.6 at 6/10. The ConfigMap encryption misconception remains the most persistent Anthropic family blindspot, shared by nearly every model except GPT 5.4 and GPT 5.5. This is also one of only two questions (with Kubelet API) where Opus 4.8 scores below 8.

Key Findings

ConfigMap encryption is widely misunderstood: The vast majority of models incorrectly stated or implied that ConfigMaps cannot be encrypted at rest. Only GPT 5.4 acknowledged that “ConfigMaps may also be covered depending on cluster encryption configuration.” Qwen 3.6 Plus repeated the same error. The EncryptionConfiguration mechanism can target any resource type, including ConfigMaps.
No model mentioned the view ClusterRole: The scoring notes highlight that ConfigMaps are included in standard RBAC roles like view while Secrets are not. This is a practical, important difference that no model identified specifically.
Base64 caveat is universally known: All five models correctly stated that base64 encoding is not encryption. This is well-understood.
API server decryption is poorly covered: The scoring notes emphasise that encryption at rest doesn’t protect against users with API access — the API server decrypts before returning data. Only GPT 5.4 came close to stating this clearly.
Intent/semantic signal is well understood: Most models captured the idea that using Secrets tells the ecosystem to treat data as sensitive, affecting tooling, backup software, and operator behaviour.
Compliance claims should be treated with caution: Gemini 3 Flash and MiniMax M2.5 referenced specific compliance frameworks (PCI-DSS, SOC2, HIPAA) without justification. Using Kubernetes Secrets doesn’t automatically satisfy compliance requirements.