Hi,
Thanks,
Ira
Probably never, IMO, unless you have an existing pervasive deployment of certificate-based identity, and it would really benefit you to re-use it.
That’s a very broad question. Assuming you mean using certificate auth to Vault from Jenkins - the documentation of https://plugins.jenkins.io/hashicorp-vault-plugin/ is, in my experience, not very good - and makes no mention of certificate auth at all. Expect to have to read the source code or use trial and error experimentation to figure out how it works if you want to go down that route.
The authenticating client needs to possess the private key. That is not the same as sending the private key over the wire. That’s a key benefit of private key cryptography.
Regarding the private key, you are right, sorry, my mistake.
It looks like that the best practice for jenkins->vault is to use HashiCorp Vault with AppRole.
They wrote in HashiCorp Vault the following:
What about other backends?
Hashicorp explicitly recommends the AppRole Backend for machine-to-machine authentication. Token based auth is mainly supported for backward compatibility. Other backends that might make sense are the AWS EC2 backend, the Azure backend, and the Kubernetes backend. But we do not support these yet. Feel free to contribute!
Or it is more secure to implement the vault login without plugin? I think cert auth is more secure. Maybe JWT auth can be used?
The best option is the one which integrates best into your overall authentication ecosystem. There is no one option that is inherently best for everyone.
If I have no authentication ecosystem in my jenkins and need to build one?
It’s probably easiest to go for AppRole then:
But one thing to bear in mind is that every time you create a new AppRole SecretID, the old ones stay valid unless you originally created them with a TTL, so unless you manually destroy the old SecretIDs via the Vault API, you potentially have lots of “passwords” that may remain valid when you might have expected otherwise.
I wonder what is more secure.
Certificate probably is, because the private key is never sent. (SecretId is sent in each login.)
From the other hand, I probably need to save the private key in regular jenkins Secret Text credential which is not secure. (I hope that hashicorp-vault-plugin’s Vault AppRole Credential saves SecretId in more secure way than regular Secret Text credential, but I am not sure.)
It depends what you mean by “more secure”. The various auth methods are all being protected by TLS for in transit encryption & identity validation. If you aren’t using HTTPS or have disabled certificate checking then every method is insecure, as you would be vulnerable for eavesdropping and man-in-the-middle attacks.
The reason the different methods exist is mostly due to the different features they offer, and to allow existing authentication systems to be reused. They are not really more or less secure then each other when used correctly (although they may all have different trade offs).
The simplest authentication option is the token method, but it is also generally the most inconvenient to manage. As @maxb says I’d not use certificate authentication unless I already had a well established certificate system already in use, due to the overhead of setting one up (and the security requirements to correctly manage such a system). Methods such as AWS or Kubernetes authentication have the advantage of allowing the reuse of security credentials you may already be using due to the use of those systems (such as from running Jenkins on a EC2 instance or within Kubernetes), but are useless if you aren’t using those systems. OIDC is primarily designed for single sign on (SSO) applications where a person can interact with a browser based central login system, so are not useful for machine authentication.
The recommended option for machine auth is AppRole unless one of the more specialist options in simpler, and that is what I would use if I don’t already have a certificate CA & management system and am not using Kubernetes or AWS.
Within Jenkins itself the plugin uses the credentials system provided by Jenkins, which is where all secrets are managed (such as Git credentials, access to other APIs, etc.). What are you meaning by your comment “I probably need to save the private key in regular jenkins Secret Text credential which is not secure”?
Yes, sure we use https and not skipping certificate checking, but it only checks the server (vault) certificate check, so we thought to add client (jenkins) certificate and from here came the idea to use cert auth.
I meant that in case we’ll use certificate auth, we’ll need to save private key in some place.
The Jenkins server will have to contain some sort of secret to be able to authenticate with Vault. This could be a certificate, a token, an AppRole role/secret or similar. It is the responsibility of Jenkins to store that secret in a secure way.
As previously mentioned if you don’t already have a CA used for client certificates I would not recommend making one to use with Vault (as it is a lot of work to create & maintain, and if not done correctly could easily remove all security). Instead I would recommend using AppRole.
Ok, thank you so much.
Just last question.
Does vault support mTLS?
Sort of but not completely.
The certificate auth method you have been talking about all thread is literally mTLS.
But, once the login operation has completed, you get back a regular Vault token, which I strongly suspect will continue to work even if you stop doing mTLS for subsequent requests!
Do you plan to implement mTLS? (Which will do for all the requests.)
This is a community help forum - not a means of communicating with HashiCorp. I have no idea what their future plans for the product include.
I would think it is pretty unlikely due to the way Vault operates. A user or application makes a login call which creates a token and associated lease. They can then use that token to perform other actions (such as creating temporary access to an AWS account). If the lease expires (which can often be extended by the user, or can be revoked) access is stopped and any leases created are also revoked (so the AWS account access immediately stops too).
With mTLS there is no separate login step, or the need to pass a login token to subsequent calls - instead every call gets separately authenticated. This is great for standard API calls for a service that doesn’t need the concept of logging in, leases & logging out.
I am in no way connected with Hashicorp, so this is just my opinion.