Knox

Knox manages managing and securing a multitude of secrets, keys, and credentials within a large and complex infrastructure. Previously, these secrets were scattered across git repositories, making them vulnerable to compromise and difficult to rotate.

Technically, Knox is built as a service with a server component that interacts with a secure data store, such as MySQL, and a cryptor for authenticated encryption. The master key for this encryption is recommended to be protected by hardware or an HSM like Amazon KMS. The client layer, which resides on machines across the fleet, caches keys locally for use by services, ensuring that keys are only accessible by authorized users and machines listed on the key-specific access control list.

Key rotation is a core feature, with each key comprising multiple versions – a primary version and active/inactive versions. This allows for gradual rotation without disrupting ongoing sessions. For example, in a scenario where a service uses a signing key, the old key version can remain active during the transition to the new key, ensuring continuity.

Operational considerations include the need for robust audit logging, where every request to Knox is logged with authentication data, enabling tracking of key access by users and machines. These logs can be integrated with tools like Elasticsearch, Logsearch, and Kibana for incident response and anomaly detection. However, key data itself is not stored in the logs to maintain confidentiality.

In terms of setup, Knox can be deployed using Go or Docker, with the client and server components compiled and run locally or within a container. The use of GitHub tokens for user authentication adds an additional layer of security and ease of use for developers. Despite its robust features, Knox's architecture must be carefully managed to ensure that the master key and access control lists are properly secured to prevent unauthorized access.