MyFavMirrors/minio
1
0
Fork 0
mirror of https://github.com/minio/minio.git synced 2025-11-09 13:39:46 -05:00
Code Issues Packages Projects Releases Wiki Activity

fix: allow parsing keys in both new and old format (#12144)

Browse Source 
Bonus fix fallback to decrypt previously
encrypted content as well using older master
key ciphertext format.

Signed-off-by: Harshavardhana <harsha@minio.io>
This commit is contained in:
Harshavardhana
2021-04-24 19:05:25 -07:00
committed by GitHub
parent 5d954ea228
commit f420996dfa
3 changed files with 119 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
docs/kms/IAM.md Normal file
View File

@@ -0,0 +1,61 @@
# KMS IAM/Config Encryption
MinIO will soon release a change that re-works the encryption of IAM and
configuration data. Currently, MinIO encrypts IAM data (user/temp. credentials,
policies and other configuration data) with the cluster root credentials before
storing it on the backend disks. After release `RELEASE.2021-04-22T15-44-28Z`
onwards, MinIO will use the KMS provided keys to encrypt the IAM data instead
of the cluster root credentials. If the KMS is not enabled, MinIO will store
the IAM data as plain text in its backend.
### FAQ
> Why is this change needed? Was the previous encryption not secure (enough)?
The previous mechanism of encryption using the cluster root credentials itself
is secure. The purpose of this change is to improve the encryption key
management by delegating it to the KMS. Once the cluster root credentials are no
longer needed to decrypt persistent data at the backend, they can be rotated
much more easily. By using a KMS to protect the IAM data a potential security or
compliance team has much more control over how/when a MinIO cluster can be
started.
> Does this mean I need an enterprise KMS setup to run MinIO (securely)?
No, MinIO does not depend on any third-party KMS provider. You have three options here:
- Run MinIO without a KMS. In this case all IAM data will be stored in plain-text.
- Run MinIO with a single secret key. MinIO supports a static cryptographic key
that can act as minimal KMS. With this method all IAM data will be stored
encrypted. The encryption key has to be passed as environment variable.
- Run MinIO with KES (minio/kes) in combination with any supported KMS as
secure key store. For example, you can run MinIO + KES + Hashicorp Vault.
> What about an exiting MinIO deployment? Can I just upgrade my cluster?
Yes, MinIO will try to transparently migrate any existing IAM data and either stores
it in plaintext (no KMS) or re-encrypts using the KMS.
> Is this change backward compatible? Will it break my setup?
This change is not backward compatible for all setups. In particular, the native
Hashicorp Vault integration - which has been deprecated already - won't be
supported anymore. KES is now mandatory if a third-party KMS should be used.
Further, since the configuration data is encrypted with the KMS, the KMS
configuration itself can no longer be stored in the MinIO config file and
instead must be provided via environment variables. If you have set your KMS
configuration using e.g. the `mc admin config` commands you will need to adjust
your deployment.
Even though this change is backward compatible we do not expect that it affects
the vast majority of deployments in any negative way.
> Will an upgrade of an existing MinIO cluster impact the SLA of the cluster or will it even cause downtime?
No, an upgrade should not cause any downtime. However, on the first startup -
since MinIO will attempt to migrate any existing IAM data - the boot process may
take slightly longer, but may not be visibly noticeable. Once the migration has
completed, any subsequent restart should be as fast as before or even faster.