Summary
The Provider protobuf message contains a map<string, string> credentials field (proto/datamodel.proto, line 85). When persisted via put_message() in crates/openshell-server/src/persistence/sqlite.rs, the serialised protobuf payload — including plaintext credentials — is written directly to the objects table with no encryption-at-rest layer.
The server correctly redacts credentials in gRPC responses via redact_provider_credentials() (crates/openshell-server/src/grpc.rs, line 4151), but the underlying storage contains plaintext secrets.
Impact
- Severity: Medium
- An attacker with read access to the SQLite database file (e.g., via container escape, backup exposure, or host compromise) can extract all provider API keys.
Proposed Fix
Implement application-level encryption for the credentials map before persistence, using a key derived from a server-side secret (e.g., a key file generated during bootstrap). Alternatively, integrate with a secrets manager (HashiCorp Vault, AWS Secrets Manager, etc.).
Summary
The
Providerprotobuf message contains amap<string, string> credentialsfield (proto/datamodel.proto, line 85). When persisted viaput_message()incrates/openshell-server/src/persistence/sqlite.rs, the serialised protobuf payload — including plaintext credentials — is written directly to theobjectstable with no encryption-at-rest layer.The server correctly redacts credentials in gRPC responses via
redact_provider_credentials()(crates/openshell-server/src/grpc.rs, line 4151), but the underlying storage contains plaintext secrets.Impact
Proposed Fix
Implement application-level encryption for the
credentialsmap before persistence, using a key derived from a server-side secret (e.g., a key file generated during bootstrap). Alternatively, integrate with a secrets manager (HashiCorp Vault, AWS Secrets Manager, etc.).