Open miguelangel-nubla opened 1 year ago
Same happens with step ca token
.
Is this by design?
cc @dopey
A workaround might be to create a certificate using that provisioner and then use it with --admin-cert
and --admin-key
As @maraino mentioned, you can always just generate the certificate and key yourself - making sure to use the x5c provisioner and the exact subject name step
. But, that is a workaround.
@miguelangel-nubla Can you tell us more about the use case, please? I'm struggling to come up with a reason for using an x5c provisioner to then provision an admin credential. If the goal is to authenticate to the admin API using an "identity" certificate (let's say one issued to a user or something like that), then using --admin-cert
and --admin-key
would be our recommended approach.
If we find that using the --admin-cert
and --admin-key
flags is suitable for use cases like yours we may want to remove the ability to add X5C admin provisioners since it's confusing and not recommended.
The use case is using hardware signing (yubikey or pkcs11) for as much as possible, as to not have the chance of a private key or passphrase leaking.
The ability to use a --x5c-cert
and --x5c-key
together with --kms
to authenticate to a provisioner reduces the attack vector considerably. An attacker with full access to your system will be limited to the actions you have signed (ideally with the touch of the yubikey), nothing more, instead of full access to the scope of the provisioner.
It just works already with ssh certificates:
step ssh certificate \
--kms "yubikey:?pin-value=123456" \
--x5c-cert "yubikey:slot-id=85" \
--x5c-key "yubikey:slot-id=85" \
--provisioner provisioner1 user
which I think is awesome.
Would love to see support for it everywhere, other more useful examples that come to mind are step ca token
and step ssh login
with the touch of a button, and no higher level secrets at risk.
Same happens with
step ca token
. Is this by design?
No, we want to support kms everywhere, but we need to dedicate time to do it, and we've only done it in the most commonly used commands.
Some time ago I created this script that you should be able to use with a YubiKey too.
Adding kms support for all the admin commands might be a bit hard, but adding it to step ca token
and adding an --admin-token
flag to the admin commands might be more manageable.
Ah, ok, that makes sense. If the cert/key are in a yubikey, then the admin middleware won't be able to correctly generate the necessary token.
We've created two new enhancements alongside this bug report -
Thanks for bringing the issue to our attention @miguelangel-nubla, and for explaining the use case.
Great, the token approach seems a good workaround until kms support is everywhere.
Some time ago I created this script that you should be able to use with a YubiKey too.
will definitely try that, thanks.
Thanks for bringing the issue to our attention @miguelangel-nubla, and for explaining the use case.
Thanks for making this open-source.
@miguelangel-nubla there's no need for the script, in master
we now have support for --kms
with step ca token
. But adding it to the admin client it's not straightforward as adding an --admin-token
flag, but I think we are close to solving it.
Steps to Reproduce
Your Environment
step
CLI Version - 0.23.2Expected Behavior
Authenticate using X5C credentials, as you can even create a Super Admin with that provisioner:
Actual Behavior
throws:
provisioner type 'X5C' requires the '--x5c-cert' flag
Additional Context
No response
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).