util: add vaultDestroyKeys option to destroy Vault kv-v2 secrets #2343
Conversation
nixpanic
added
enhancement
|
@nixpanic CI failure. |
nixpanic
force-pushed
the
rbd/encryption/vault/destroy-v2-keys
branch
from
3d4618c
to
b614f13
Compare
|
/test ci/centos/mini-e2e-helm/k8s-1.19 |
|
nixpanic
force-pushed
the
rbd/encryption/vault/destroy-v2-keys
branch
from
b614f13
to
804d2e4
Compare
Sure, we default to kv-v2 in our testing, and that always supports the metadata for keys. A new commit has been added that enables checking for the metadata after deletion (should have been removed as well). |
|
@Mergifyio rebase #2349 has been merged, pulling the CentOS images should work again. |
nixpanic
force-pushed
the
rbd/encryption/vault/destroy-v2-keys
branch
from
804d2e4
to
67b9d72
Compare
|
Command
|
|
/retest ci/centos/mini-e2e-helm/k8s-1.19 |
| for k, v := range vc.keyContext { | ||
| keyContext[k] = v | ||
| } |
There was a problem hiding this comment.
@nixpanic do we need this new map generation or add key to existing map?
There was a problem hiding this comment.
Adding it to the existing map will cause failures during non-delete operations. So, creating a copy of the map and adding it there.
|
/test ci/centos/mini-e2e-helm/k8s-1.20 |
|
|
@pkalever Looks like some nbd related failed https://jenkins-ceph-csi.apps.ocp.ci.centos.org/blue/rest/organizations/jenkins/pipelines/mini-e2e-helm_k8s-1.20/runs/1891/nodes/110/steps/113/log/?start=0 PTAL |
|
This pull request now has conflicts with the target branch. Could you please resolve conflicts and force push the corrected changes? 🙏 |
nixpanic
force-pushed
the
rbd/encryption/vault/destroy-v2-keys
branch
from
67b9d72
to
efd53f5
Compare
|
@Mergifyio rebase |
libopenstorage has added a new feature that makes it possible to destroy the contents of a key/value in the Hashicorp Vault kv-v2 secrets backend. See-also: libopenstorage/secrets#55 Signed-off-by: Niels de Vos <ndevos@redhat.com>
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>
Golang-ci complains about the following:
internal/util/vault_tokens.go:99:20: string `true` has 4 occurrences, but such constant `vaultDefaultDestroyKeys` already exists (goconst)
v.VaultCAVerify = "true"
^
This occurence of "true" can be replaced by vaultDefaultCAVerify so
address the warning.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
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>
nixpanic
force-pushed
the
rbd/encryption/vault/destroy-v2-keys
branch
from
efd53f5
to
e2ea5d9
Compare
|
Command
|
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
vaultDestroyKeysconfiguration parameter, this behaviourcan 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.
See-also: libopenstorage/secrets#55
Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:
/retest ci/centos/<job-name>: retest the<job-name>after unrelatedfailure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any testprogress or results