You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should add a validating webhook to ensure the peer key is a known key for the cluster. We find that some teams have deployed lockboxes for one cluster into another, and are surprised when their secrets are not created. We should prevent this by returning an error during deployment.
The text was updated successfully, but these errors were encountered:
I can confirm that using the most recent CRDs (and the only open source versions) does prevent non-base64 secrets from being created with an, albeit verbose, error:
The Lockbox "top-secret" is invalid: spec.data.secret: Invalid value: "RatzHMvG5zRph50S4ZZgQrJ5pVqmDYBOrpuAhwQ5alz4mGF5+cT16Y9nxhAi+j9ots03/b9rcecNvIg==": spec.data.secret in body must be of type byte: "RatzHMvG5zRph50S4ZZgQrJ5pVqmDYBOrpuAhwQ5alz4mGF5+cT16Y9nxhAi+j9ots03/b9rcecNvIg==
We should add a validating webhook to ensure the peer key is a known key for the cluster. We find that some teams have deployed lockboxes for one cluster into another, and are surprised when their secrets are not created. We should prevent this by returning an error during deployment.
The text was updated successfully, but these errors were encountered: