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
Is your feature request related to a problem? Please describe.
When sealing a secret which has a namespace specified, the --namespace option on the kubeseal command line is ignored.
I've found that users often end up creating secrets that can't be unsealed, because they don't realise that they have sealed them to the wrong namespace.
e.g., kubectl get secret whatever -n ns1 | kubeseal -n ns2 outputs a secret sealed for ns1 but I expected it to be sealed for ns2.
Describe the solution you'd like
If the namespace on the input secret differs from the namespace specified on the command line, kubeseal should fail with an error.
error: refusing to seal secret from ns1 to ns2
Not a very good error message but I think you get the idea.
Describe alternatives you've considered
kubeseal could maintain its existing behaviour, but print a warning (but users tend to ignore warnings)
kubeseal could allow the --namespace option to override the namespace on the input secret (might silently break existing workflows)
kubeseal could allow the --namespace option to override the namespace on the input secret if --override-namespace is also specified (and fail or print a warning otherwise)
The text was updated successfully, but these errors were encountered:
Which component:
kubeseal version: 0.17.5
Is your feature request related to a problem? Please describe.
When sealing a secret which has a namespace specified, the
--namespace
option on thekubeseal
command line is ignored.I've found that users often end up creating secrets that can't be unsealed, because they don't realise that they have sealed them to the wrong namespace.
e.g.,
kubectl get secret whatever -n ns1 | kubeseal -n ns2
outputs a secret sealed forns1
but I expected it to be sealed forns2
.Describe the solution you'd like
If the namespace on the input secret differs from the namespace specified on the command line,
kubeseal
should fail with an error.error: refusing to seal secret from ns1 to ns2
Not a very good error message but I think you get the idea.
Describe alternatives you've considered
kubeseal
could maintain its existing behaviour, but print a warning (but users tend to ignore warnings)kubeseal
could allow the--namespace
option to override the namespace on the input secret (might silently break existing workflows)kubeseal
could allow the--namespace
option to override the namespace on the input secret if--override-namespace
is also specified (and fail or print a warning otherwise)The text was updated successfully, but these errors were encountered: