mirrors/ceph-csi
1
0
Fork 0
mirror of https://github.com/ceph/ceph-csi.git synced 2024-12-26 15:00:19 +00:00
Code Issues Packages Projects Releases Wiki Activity
dependabot/go_modules/github-dependencies-9af0b9bf61
ceph-csi/examples/kms/vault/kms-config.yaml

122 lines
4.4 KiB
YAML
Raw Permalink Normal View History

Adds per volume encryption with Vault integration - adds proposal document for PVC encryption from PR448 - adds per-volume encription by generating encryption passphrase for each volume and storing it in a KMS - adds HashiCorp Vault integration as a KMS for encryption passphrases - avoids encrypting volume second time if it was already encrypted but no file system created - avoids unnecessary checks if volume is a mapped device when encryption was not requested - prevents resizing encrypted volumes (it is not currently supported) - prevents creating snapshots from encrypted volumes to prevent attack on encryption key (security guard until re-encryption of volumes implemented) Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com Fixes #420 Fixes #744
2020-01-29 11:44:45 +00:00
---
apiVersion: v1
kind: ConfigMap
data:
config.json: |-
Reduce encryption KMS configuration SC parameters * moves KMS type from StorageClass into KMS configuration itself * updates omapval used to identify KMS to only it's ID without the type why? 1. when using multiple KMS configurations (not currently supported) automated parsing of kms configuration will be failing because some entries in configs won't comply with the requested type 2. less options are needed in the StorageClass and less data used to identify the KMS Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com
2020-02-06 16:23:14 +00:00
{
"vault-test": {
"encryptionKMSType": "vault",
Adds per volume encryption with Vault integration - adds proposal document for PVC encryption from PR448 - adds per-volume encription by generating encryption passphrase for each volume and storing it in a KMS - adds HashiCorp Vault integration as a KMS for encryption passphrases - avoids encrypting volume second time if it was already encrypted but no file system created - avoids unnecessary checks if volume is a mapped device when encryption was not requested - prevents resizing encrypted volumes (it is not currently supported) - prevents creating snapshots from encrypted volumes to prevent attack on encryption key (security guard until re-encryption of volumes implemented) Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com Fixes #420 Fixes #744
2020-01-29 11:44:45 +00:00
"vaultAddress": "http://vault.default.svc.cluster.local:8200",
"vaultAuthPath": "/v1/auth/kubernetes/login",
"vaultRole": "csi-kubernetes",
util: allow configuring VAULT_BACKEND for Vault connection It seems that the version of the key/value engine can not always be detected for Hashicorp Vault. In certain cases, it is required to configure the `VAULT_BACKEND` (or `vaultBackend`) option so that a successful connection to the service can be made. The `kv-v2` is the current default for development deployments of Hashicorp Vault (what we use for automated testing). Production deployments default to version 1 for now. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-20 09:18:58 +00:00
"vaultBackend": "kv-v2",
util: add vaultDestroyKeys option to destroy Vault kv-v2 secrets Hashicorp Vault does not completely remove the secrets in a kv-v2 backend when the keys are deleted. The metadata of the keys will be kept, and it is possible to recover the contents of the keys afterwards. With the new `vaultDestroyKeys` configuration parameter, this behaviour can now be selected. By default the parameter will be set to `true`, indicating that the keys and contents should completely be destroyed. Setting it to any other value will make it possible to recover the deleted keys. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-08-02 09:35:26 +00:00
"vaultDestroyKeys": "true",
Adds per volume encryption with Vault integration - adds proposal document for PVC encryption from PR448 - adds per-volume encription by generating encryption passphrase for each volume and storing it in a KMS - adds HashiCorp Vault integration as a KMS for encryption passphrases - avoids encrypting volume second time if it was already encrypted but no file system created - avoids unnecessary checks if volume is a mapped device when encryption was not requested - prevents resizing encrypted volumes (it is not currently supported) - prevents creating snapshots from encrypted volumes to prevent attack on encryption key (security guard until re-encryption of volumes implemented) Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com Fixes #420 Fixes #744
2020-01-29 11:44:45 +00:00
"vaultPassphraseRoot": "/v1/secret",
"vaultPassphrasePath": "ceph-csi/",
Reduce encryption KMS configuration SC parameters * moves KMS type from StorageClass into KMS configuration itself * updates omapval used to identify KMS to only it's ID without the type why? 1. when using multiple KMS configurations (not currently supported) automated parsing of kms configuration will be failing because some entries in configs won't comply with the requested type 2. less options are needed in the StorageClass and less data used to identify the KMS Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com
2020-02-06 16:23:14 +00:00
"vaultCAVerify": "false"
e2e: add test for VaultTokensKMS support Signed-off-by: Niels de Vos <ndevos@redhat.com>
2020-12-09 16:10:43 +00:00
},
"vault-tokens-test": {
"encryptionKMSType": "vaulttokens",
"vaultAddress": "http://vault.default.svc.cluster.local:8200",
util: allow configuring VAULT_BACKEND for Vault connection It seems that the version of the key/value engine can not always be detected for Hashicorp Vault. In certain cases, it is required to configure the `VAULT_BACKEND` (or `vaultBackend`) option so that a successful connection to the service can be made. The `kv-v2` is the current default for development deployments of Hashicorp Vault (what we use for automated testing). Production deployments default to version 1 for now. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-20 09:18:58 +00:00
"vaultBackend": "kv-v2",
e2e: add test for VaultTokensKMS support Signed-off-by: Niels de Vos <ndevos@redhat.com>
2020-12-09 16:10:43 +00:00
"vaultBackendPath": "secret/",
"vaultTLSServerName": "vault.default.svc.cluster.local",
"vaultCAVerify": "false",
"tenantConfigName": "ceph-csi-kms-config",
"tenantTokenName": "ceph-csi-kms-token",
"tenants": {
"my-app": {
"vaultAddress": "https://vault.example.com",
"vaultCAVerify": "true"
},
"an-other-app": {
util: add vaultDestroyKeys option to destroy Vault kv-v2 secrets Hashicorp Vault does not completely remove the secrets in a kv-v2 backend when the keys are deleted. The metadata of the keys will be kept, and it is possible to recover the contents of the keys afterwards. With the new `vaultDestroyKeys` configuration parameter, this behaviour can now be selected. By default the parameter will be set to `true`, indicating that the keys and contents should completely be destroyed. Setting it to any other value will make it possible to recover the deleted keys. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-08-02 09:35:26 +00:00
"tenantTokenName": "storage-encryption-token",
"vaultDestroyKeys": "false"
e2e: add test for VaultTokensKMS support Signed-off-by: Niels de Vos <ndevos@redhat.com>
2020-12-09 16:10:43 +00:00
}
}
e2e: add test for the SecretsMetadataKMS provider The new provider should be able to provision and mount an encrypted volume. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-03-04 09:23:53 +00:00
},
doc: add example for Tenant ServiceAccount The ServiceAccount "ceph-csi-vault-sa" is expected to be placed in the Namespace "tenant" so that the provisioner and node-plugin fetch the ServiceAccount from a Namespace where Ceph-CSI is not deployed. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-06 08:32:12 +00:00
"vault-tenant-sa-test": {
"encryptionKMSType": "vaulttenantsa",
"vaultAddress": "http://vault.default.svc.cluster.local:8200",
util: allow configuring VAULT_BACKEND for Vault connection It seems that the version of the key/value engine can not always be detected for Hashicorp Vault. In certain cases, it is required to configure the `VAULT_BACKEND` (or `vaultBackend`) option so that a successful connection to the service can be made. The `kv-v2` is the current default for development deployments of Hashicorp Vault (what we use for automated testing). Production deployments default to version 1 for now. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-20 09:18:58 +00:00
"vaultBackend": "kv-v2",
doc: add example for Tenant ServiceAccount The ServiceAccount "ceph-csi-vault-sa" is expected to be placed in the Namespace "tenant" so that the provisioner and node-plugin fetch the ServiceAccount from a Namespace where Ceph-CSI is not deployed. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-06 08:32:12 +00:00
"vaultBackendPath": "shared-secrets",
e2e: add verifyKeyDestroyed() for validating `vaultDestroyKeys` The kmsConfig type in the e2e suite has been enhanced with two functions that make it possible to validate the destruction of deleted keys. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-08-03 09:27:12 +00:00
"vaultDestroyKeys": "false",
doc: add example for Tenant ServiceAccount The ServiceAccount "ceph-csi-vault-sa" is expected to be placed in the Namespace "tenant" so that the provisioner and node-plugin fetch the ServiceAccount from a Namespace where Ceph-CSI is not deployed. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-06 08:32:12 +00:00
"vaultTLSServerName": "vault.default.svc.cluster.local",
"vaultCAVerify": "false",
"tenantConfigName": "ceph-csi-kms-config",
"tenantSAName": "ceph-csi-vault-sa",
"tenants": {
"my-app": {
"vaultAddress": "https://vault.example.com",
"vaultCAVerify": "true"
},
"an-other-app": {
"tenantSAName": "storage-encryption-sa"
}
}
},
util: add vaultAuthNamespace option for Vault KMS The new `vaultAuthNamespace` configuration parameter can be set to the Vault Namespace where the authentication is setup in the service. Some Hashicorp Vault deployments use sub-namespaces for their users/tenants, with a 'root' namespace where the authentication is configured. This requires passing of different Vault namespaces for different operations. Example: - the Kubernetes Auth mechanism is configured for in the Vault Namespace called 'devops' - a user/tenant has a sub-namespace called 'devops/website' where the encryption passphrases can be placed in the key-value store The configuration for this, then looks like: vaultAuthNamespace: devops vaultNamespace: devops/homepage Note that Vault Namespaces are a feature of the Hashicorp Vault Enterprise product, and not part of the Open Source version. This prevents adding e2e tests that validate the Vault Namespace configuration. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-07-30 07:53:27 +00:00
"vault-tenant-sa-ns-test": {
"encryptionKMSType": "vaulttenantsa",
"vaultAddress": "http://vault.default.svc.cluster.local:8200",
"vaultBackend": "kv-v2",
"vaultBackendPath": "shared-secrets",
"vaultAuthNamespace": "devops",
"vaultNamespace": "devops/homepage",
"vaultTLSServerName": "vault.default.svc.cluster.local",
"vaultCAVerify": "false",
"tenantConfigName": "ceph-csi-kms-config",
"tenantSAName": "ceph-csi-vault-sa",
"tenants": {
"webservers": {
"vaultAddress": "https://vault.example.com",
"vaultAuthNamespace": "webservers",
"vaultNamespace": "webservers/homepage",
"vaultCAVerify": "true"
},
"homepage-db": {
"vaultNamespace": "devops/homepage/database",
"tenantSAName": "storage-encryption-sa"
}
}
},
e2e: add test for the SecretsMetadataKMS provider The new provider should be able to provision and mount an encrypted volume. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-03-04 09:23:53 +00:00
"secrets-metadata-test": {
"encryptionKMSType": "metadata"
e2e: add e2e for user secret based metadata encryption This commit adds e2e for user secret based metadata encryption, adds user-secret.yaml and makes required changes in kms-connection-details, kms-config yamls. Signed-off-by: Rakshith R <rar@redhat.com>
2021-07-05 08:28:33 +00:00
},
"user-ns-secrets-metadata-test": {
"encryptionKMSType": "metadata",
"secretName": "storage-encryption-secret",
"secretNamespace": "default"
},
"user-secrets-metadata-test": {
"encryptionKMSType": "metadata",
"secretName": "storage-encryption-secret"
rbd: Implement Key Protect KMS integration for Ceph CSI This commit adds the support for HPCS/Key Protect IBM KMS service to Ceph CSI service. EncryptDEK() and DecryptDEK() of RBD volumes are done with the help of key protect KMS server by wrapping and unwrapping the DEK and by using the DEKStoreMetadata. Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
2021-12-20 05:49:54 +00:00
},
rbd: change the keyprotect metadata name to `ibmkeyprotect` To be consistent with other components and also to explictly state it belong to `ibm keyprotect` service introducing this change Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
2022-01-24 09:09:31 +00:00
"ibmkeyprotect-test": {
"encryptionKMSType": "ibmkeyprotect",
rbd: Implement Key Protect KMS integration for Ceph CSI This commit adds the support for HPCS/Key Protect IBM KMS service to Ceph CSI service. EncryptDEK() and DecryptDEK() of RBD volumes are done with the help of key protect KMS server by wrapping and unwrapping the DEK and by using the DEKStoreMetadata. Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
2021-12-20 05:49:54 +00:00
"secretName": "ceph-csi-kp-credentials",
"keyProtectRegionKey": "us-south-2",
"keyProtectServiceInstanceID": "7abef064-01dd-4237-9ea5-8b3890970be3"
rbd: add `aws-sts-metdata` encryption type With Amazon STS and kubernetes cluster is configured with OIDC identity provider, credentials to access Amazon KMS can be fetched using oidc-token(serviceaccount token). Each tenant/namespace needs to create a secret with aws region, role and CMK ARN. Ceph-CSI will assume the given role with oidc token and access aws KMS, with given CMK to encrypt/decrypt DEK which will stored in the image metdata. Refer: https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html Resolves: #2879 Signed-off-by: Rakshith R <rar@redhat.com>
2022-03-02 10:30:48 +00:00
},
"aws-sts-metadata-test": {
"encryptionKMSType": "aws-sts-metadata",
"secretName": "ceph-csi-aws-credentials"
rbd: add kmip encryption type The Key Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. Ceph-CSI can now be configured to connect to various KMS using KMIP for encrypting RBD volumes. https://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol Signed-off-by: Rakshith R <rar@redhat.com>
2022-08-16 09:47:05 +00:00
},
"kmip-test": {
"KMS_PROVIDER": "kmip",
"KMIP_ENDPOINT": "kmip:5696",
"KMIP_SECRET_NAME": "ceph-csi-kmip-credentials",
"TLS_SERVER_NAME": "kmip.ciphertrustmanager.local",
"READ_TIMEOUT": 10,
"WRITE_TIMEOUT": 10
kms: Implement Azure key vault as KMS provider This commit adds the Azure Key Vault as a supported KMS provider. Signed-off-by: Praveen M <m.praveen@ibm.com>
2024-02-16 10:05:08 +00:00
},
"azure-test": {
"KMS_PROVIDER": "azure-kv",
"AZURE_CERT_SECRET_NAME": "ceph-csi-azure-credentials",
"AZURE_VAULT_URL": "https://vault-name.vault.azure.net/",
"AZURE_CLIENT_ID": "__CLIENT_ID__",
"AZURE_TENANT_ID": "__TENANT_ID__"
e2e: add test for the SecretsMetadataKMS provider The new provider should be able to provision and mount an encrypted volume. Signed-off-by: Niels de Vos <ndevos@redhat.com>
2021-03-04 09:23:53 +00:00
}
Reduce encryption KMS configuration SC parameters * moves KMS type from StorageClass into KMS configuration itself * updates omapval used to identify KMS to only it's ID without the type why? 1. when using multiple KMS configurations (not currently supported) automated parsing of kms configuration will be failing because some entries in configs won't comply with the requested type 2. less options are needed in the StorageClass and less data used to identify the KMS Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com
2020-02-06 16:23:14 +00:00
}
Adds per volume encryption with Vault integration - adds proposal document for PVC encryption from PR448 - adds per-volume encription by generating encryption passphrase for each volume and storing it in a KMS - adds HashiCorp Vault integration as a KMS for encryption passphrases - avoids encrypting volume second time if it was already encrypted but no file system created - avoids unnecessary checks if volume is a mapped device when encryption was not requested - prevents resizing encrypted volumes (it is not currently supported) - prevents creating snapshots from encrypted volumes to prevent attack on encryption key (security guard until re-encryption of volumes implemented) Signed-off-by: Vasyl Purchel vasyl.purchel@workday.com Signed-off-by: Andrea Baglioni andrea.baglioni@workday.com Fixes #420 Fixes #744
2020-01-29 11:44:45 +00:00
metadata:
name: ceph-csi-encryption-kms-config
Reference in New Issue Copy Permalink