feat(key-manager): add a page explaining the difference between secret manager and key manager

identity-and-access-management/key-manager/reference-content/differences-between-secret-manager-and-key-manager.mdx

@@ -0,0 +1,84 @@
+---
+meta:
+  title: What is the difference between Key Manager and Secret Manager?
+  description: Learn the differences between Key Manager and Secret Manager and which one to use according to your needs
+content:
+  h1: What is the difference between Key Manager and Secret Manager?
+  paragraph: Learn the differences between Key Manager and Secret Manager and which one to use according to your needs
+tags: key-manager secret-manager security
+dates:
+  validation: 2024-08-28
+---
+
+
+
+Secret Manager and Key Manager are both security-focused products aiming
+to help you protect your data and improve the security of your
+infrastructure.
+The difference between them is not always clear, and it is natural
+to ask which one you need according to your use-case.
+
+This document helps you answer that question.
+
+
+## Secret Manager
+
+The Secret Manager stores various secrets that your applications wants to
+access at some point. For example, when your application needs to call
+an external API service or connect to a database, it fetches the API token
+or the credentials from the Secret Manager before proceeding.
+
+Secrets can be pretty much everything you want: API tokens,
+credentials to connect to a database, sensible data.
+There is no limitation, if not the size of the secrets.
+
+
+## Key Manager
+
+In contrast, Key Manager only stores cryptographic keys.
+
+At first, the Key Manager seems to be just a restricted version of
+the Secret Manager, only for keys.
+It is indeed true that the Secret Manager could also store cryptographic keys
+and hand over the keys to applications that need to perform cryptographic operations.
+
+However, this approach is full of pitfalls and can lead to serious security problems:
+
+ - Inadvertently storing the keys in plaintext, or exposing them (<i>e.g.</i>, in logs)
+ - Incorrect (re-)use of key: your application would be responsible to use the key correctly,
+   which is harder than it looks.
+ - Not disposing the key properly after use (<i>e.g.</i>, letting it reside in swap disk)
+
+They are typical key management problems, and the Secret Manager does not solve them
+effectively, hence the need of the Key Manager.
+
+The Key Manager simply does **not** gives you any key.
+All keys residing in the Key Manager never (and never will) leave the Key Manager, since
+there is no way to extract them by design.
+
+Since you cannot have the key, the Key Manager performs the cryptographic operations
+for you: your application supplies the plaintext to be encrypted, or
+the ciphertext to be decrypted. That means your application is no longer
+responsible of managing the keys and using them properly, the Key Manager takes care of it.
+
+Last, but not least, the Key Manager provides another way of authorizing some actions.
+You might want to authorize some principals to only encrypt data, and other
+principals to only decrypt data.
+
+For example, imagine an application that receives
+some sensible health data that needs to be encrypted before being inserted into
+a database. Such an application would have the privilege to ask the Key Manager
+encryption operations, but not decryption opeartions, so it cannot read sensible
+data already stored.
+
+This is not possible to achieve with Secret Manager, since both writing and reading
+applications would need at least the privilege of reading the key from the Secret Manager,
+which is sufficient to both encrypt and decrypt the data.
+
+
+## Conclusion
+
+Cryptographic keys are secrets that need special care, and the Key Manager
+is an effective tool to helps you manage them securely,
+allowing your application to offload all the sensible cryptographic
+operations and keep keys out-of-band for extra security.