Security Model for DevOps Secrets Safe

The three components considered in the security model are: the DSS client, the DSS server, and the persisted datastore external to the DSS server.

All communication between DSS clients and DSS server is encrypted using Transport Layer Security (TLS). Secrets at rest in the persisted datastore are encrypted using 256-bit Advanced Encryption Standard - Galois/Counter Mode (AES-GCM) encryption.

DSS stores its encrypted and plaintext data in the persisted datastore external to the DSS product. Even though the secret data is encrypted in the datastore, access to the DSS database must be strictly limited to maintain security for the system.

DSS Encryption and the Master Key

DSS encrypts secrets using 256-bit AES-GCM cryptography. The encryption keys used for secrets are themselves protected using RSA encryption with a 3072-bit key. This key is called the master key.

The first time a DSS instance is launched, it starts in an uninitialized and sealed state. There is no master key yet, and no secret encryption keys are present. Initialization is required to set the initial root password and to generate the master key.

An initialization request to the DSS API specifies the initial root password and causes generation of the master key that is returned from the API. The master key must be handled securely, as it is the only piece of information required to unseal the DSS instance.

  • The master key is returned as a JSON blob containing the RSA private key.
  • A copy of this key must be retained by the operator as the DSS instance cannot be unsealed without it.
  • Immediately after initialization, the DSS instance is still sealed and most endpoints remain unavailable.

Unsealing DSS using the master key is required after initialization to enable the system's cryptographic services. The system becomes unsealed when the master key is provided to the API in an unseal request. Encryption keys are only available to DSS when the system is operating in its unsealed state.

The DSS instance returns to the sealed state when any of the following occur:

  • DSS is restarted
  • DSS is upgraded
  • When a seal operation is commanded via the API

Authentication and Authorization

DSS enforces that all API requests aside from initialization, unsealing, and login require authentication. Authentication is verified using a token in the header of requests sent to the DSS API. Tokens are obtained for users from the internal identity provider by user name and password, or for applications using API key credentials. Multi-factor authentication can be configured for users. External identity providers can be configured, enabling use of different credential types and use of identity information sourced from external systems.

Authenticated DSS principals can only access resources in DSS they have permissions for. Access rights to DSS resources are computed using Access Control Entries (ACE) that consist of three elements:

  • Principal: The identity of a user, application, or group in DSS.
  • Resource: The URI path for a resource in DSS.
  • Operation: The available operations are Create, Read, Update, Delete, and Grant.

Each access control entry can indicate that the operation is allowed or can be an explicit denial entry. Any denial rule takes precendence over conflicting allow rules.

Authorization can be further restricted based on the requesting client's IP address using DSS's safelist functionality.

Auditing

DSS can generate an audit event log for all API requests and responses. Auditing for DSS is configured using the Event Sink API. Audit events can be delivered as text to the console or as structured events to an aggregator like ELK or syslog.

All system actions undertaken to service a request are audited, and audit events for a particular request are associated by a common Correlation ID.

Log aggregation and visualization tools such as Elasticsearch and Kibana provide a convenient means for exploring audit information sent from DSS.

Threats to DSS Security

The following threats to DSS security cannot be mitigated by the application itself. Mitigation of these threats requires proper administration and security controls for the DSS server and its external datastore.

  1. DSS cannot prevent against disruption of the system in the event that an attacker gains control of the persisted datastore external to the DSS server. In the event that the security of the DSS datastore is compromised, an operator with arbitrary control of the DSS database can circumvent the product's security in ways that cannot be mitigated. For example:
    • The attacker could delete the database entirely, or selectively.
    • The attacker could roll back database changes to an earlier state.
    • The attacker could infer the existence of secret material even though the secret contents remain encrypted.

 

Security of the external datastore must be strictly maintained to protect against these threats.

  1. DSS cannot protect against memory analysis of the DSS server application software. An attacker with root access to the DSS cluster nodes and the ability to perform runtime analysis could feasibly compromise sensitive data secured by DSS.