是否应将非机密与机密配置分存？分存/共存的其他技术考量？

Great question—let’s break this down into clear technical tradeoffs since there’s no one-size-fits-all answer here.

Reasons to Store Non-Confidential KV in Consul (Instead of Vault) #

• Performance Overhead: You already called this out, but it’s worth expanding. Vault encrypts/decrypts every entry, logs every access, and enforces strict ACL checks on all requests. For high-throughput, frequently read non-confidential configs (like feature flags, service endpoints, or default settings), this adds unnecessary latency and resource bloat. Consul is built specifically for fast, scalable KV operations without these extra security layers, making it far more efficient for non-sensitive data.
• Service Discovery Synergy: Consul’s core superpower is service discovery. Pairing non-confidential configs with your service registry lets you build tight, dynamic integrations—like updating a feature flag automatically when a new service instance spins up. Vault has no native service discovery, so you’d lose that cohesion if you moved all configs there.
• Simpler Operations for Non-Sensitive Data: Consul’s ACL model is lightweight compared to Vault’s granular, lease-based policies. You don’t need to manage token renewals, complex permission sets, or secret rotation workflows just to let services read basic configs. This reduces friction for teams that don’t need Vault’s heavy security controls for their non-sensitive data.
• Cost Efficiency: Vault’s storage (especially with persistent audit logs and encryption at rest) can be pricier than Consul’s lightweight KV store. If you have tons of non-confidential configs, storing them in Consul cuts down on infrastructure costs and the operational overhead of managing encrypted storage for data that doesn’t need it.

Technical Arguments For Co-Locating All Configs in Vault #

• Unified Configuration Plane: Managing one system instead of two reduces cognitive load for your team. You can use the same CLI, APIs, and access workflows for both secrets and non-confidential configs—no switching between tools or learning separate permission models. This is a huge win for small teams or environments with limited DevOps bandwidth.
• Robust Auditing & Versioning: Even non-confidential configs can benefit from Vault’s audit trails and version history. If a critical setting (like a database connection timeout) gets changed accidentally, you can trace who made the change, when, and roll back to a previous version in seconds. Consul has basic versioning, but Vault’s is far more robust for compliance-focused teams.
• Consistent Security Controls: If you already use Vault for secrets, extending its ACL policies to non-confidential configs ensures a uniform security model. You don’t have to maintain separate permission sets across two systems, which reduces the risk of misconfigurations or over-permissions.
• Less Operational Overhead: Running two distributed systems means double the monitoring, backups, and upgrades. Consolidating into Vault simplifies your infrastructure stack—you only need to monitor one service, run one backup process, and apply updates once.

Technical Arguments Against Co-Locating All Configs in Vault #

• Performance Bottlenecks: As you noted, Vault’s security features introduce measurable overhead. For workloads that read non-confidential configs thousands of times per second, this latency can add up and degrade application performance. Consul’s KV is optimized for high throughput, making it a better fit for these use cases.
• Increased Blast Radius: If Vault goes down (due to an outage, misconfiguration, or maintenance), all your configs—confidential and non-confidential—become unavailable. Separating them means a Consul outage only affects non-sensitive data, and vice versa, reducing the impact of single points of failure.
• Rate Limiting Constraints: Vault enforces strict rate limits to prevent abuse, which can interfere with high-volume reads of non-confidential configs. You might hit limits during traffic spikes, even if you’re not doing anything malicious. Consul has more flexible rate limiting that’s tailored for frequent, non-sensitive access.
• Complex Backup & Recovery: Vault’s backup process is involved because it handles encrypted data and requires careful key management. If you include non-confidential configs in Vault, you’re tying their backup/recovery to Vault’s more complex workflow—unnecessary overhead for data that doesn’t need that level of protection.

Should You Store Non-Confidential Configs in Vault? #

It boils down to your team’s priorities:

• Go with Vault if: You value a unified toolchain, need audit trails for all config changes, or have limited resources to maintain multiple systems. This works well for small to medium teams or environments where non-confidential config volume is low.
• Go with Consul (separate from Vault) if: You have high-throughput config read workloads, need service discovery integration, or want to minimize operational overhead for non-sensitive data. This is ideal for large-scale environments or teams where performance and scalability are top priorities.

内容的提问来源于stack exchange，提问作者yosefrow