Vault: Kerberos authentication

[sethvargo]

Support kerberos as an authentication backend.

There has been some requests from the community for Kerberos as an auth backend. This is not something we plan to implement on the Vault core team, but this is something we would gladly accept a community contribution for.

If you are interested in this feature, please click the "Subscribe" button on the right hand-side.

[F21]

This would be really awesome!

We're currently looking into authentication for hdfs and hbase and they both support kerberos for authentication.

Since a lot of other services support kerberos, having this implemented means vault will be able to support a lot of services.

[darkn3rd]

Kerberos would be great for AD integration, SAMBA4, or homegrown Kerberos realm.

Normally, in AD, LDAP is secured through Kerberos, requiring service tickets that grant access. With only LDAP support, the system admin has to open up pure LDAP (389) or secure it if a PKI CA infrastructure is in place with LDAPS (636), which in this scenario adds further complexity. This also increases the attack surface by opening up an attack vector that would be unnecessary if Kerberos was supported. Therefore, lack of support for this feature will ultimately force an administrator to slightly compromise the security of the infrastructure to support Vault.

[douardda]

I'm also interested in this feature. Does anyone already started to work on this?

[douardda]

Possible candidates for this is https://github.com/apcera/gssapi (gokerb seems pretty dead). Did any one gave a glimpse at this?

[F21]

I thought I would start some discussion to work out a design of what this might look like.

For some background, my use case for kerberos is to run a secured hdfs, hbase and zookeeper cluster.

Without vault, you would set up a kerberos KDC add the hdfs, hbase and zookeeper servers to the KDC as principals, copy the keytabs to each server, setup some config and then the servers will deal with renewing tickets and so on.

If we now put vault into the mix, the advantage is that we can deal with access polices in 1 place, vault. However, some complications will be introduced into how the services work as kerberos' ticket protocol is quite similar to vault's leasing and renewals.

I can think of 3 ways this could be implemented:

1. Vault acts as a proxy infront of the KDC. So, if we request access through vault, vault would create new principals in the KDC on the fly and grant appropriate access. This would make the kerberos backend work like the current backends for mysql, aws etc. The disadvantage of this is that hdfs, hbase etc are now considered clients to vault. That means we need to build a coprocess for hdfs and friends that will talk to vault over http to lease and renew with the KDC and rotate the keytabs. I am not sure if keytabs in hdfs, hbase and zookeeper can be rotated without a restart.
2. Vault acts as a proxy infront of the KDC, but only serves client apps. Hdfs, hbase and zookeeper would communicate directly with the KDC and never talks to vault. We only talk to vault to request access through our client apps that need to access hdfs or hbase. Vault would impersonate the client app and retrieve a ticket. The client would use that ticket to communicate and get access to appropriate resources in hdfs etc. The disadvantage is that auth policies are split between kerberos and vault. And since the client gets a ticket from vault and uses that to talk with the services over the kerberos protocol, why not just do everything directly against the KDC in the first place?
3. Vault is also a keberos KDC. This means that all policies can be managed in vault and services such has hdfs, hbase etc and talk directly to vault as it is now a real KDC. The obvious disadvantage is that implementing a keberos KDC in vault is not exactly trivial. Also, vault would need to open an extra port for the KDC which means that this is not simply a backend any more. This would probably be the best way to do it, but is also probably the least likely due to the scope and the amount of changes to vault needed.
4. Maybe another option I missed?

Let me know what you guys think about this.

[jefferai]

One thing to be aware of is that we are unlikely to add any feature to Vault that requires cgo. I'm unfortunately not aware of any Kerberos-related libraries for Go that fit this requirement.

You're right about Vault's leading and renewals looking similar to Kerberos tickets...the original author of Vault have a lot of Kerberos love!

[tasdienes]

Hi @jefferai, I'd be interested to know more about the objection to cgo. Are there technical or business reasons that you can share?
Thanks!

[jefferai]

@tasdienes Non-portability across libc implementations/versions, non-deterministic behavior across libc impementations/versions, non-portability of the final binaries, much larger attack surface (LD_PRELOAD attacks and the like)...

[RobSkye]

Would be great to support kerberos or maybe some kerberos backends (LDAP,db2..) as secrets backends. With this support , vault can be used to provide kerberos credentials to client apps using, for example, APP ID auth or ec2 auth. This is a easy way to manage credentials for apps running in immutable infraestructure, containers, etc.

[jgcallero]

I will be working on a Kerberos authentication backend proof of concept under a 1099 with Smartsheet, if successful I will be attempting to build the backend fully. I will be updating and using this library https://github.com/jgcallero/gokerb as necessary to avoid the issue that gssapi had of using cgo.

Is there anything I should be aware of while developing this?

[jefferai]

@jgcallero You should come up with an RFC that details how the backend will work, what the endpoints will be, what the parameters will be, and so on.

[tasdienes]

Hi @jgcallero I'm quite interested in your project. Is it progressing well?
Thanks,
Tas

[jgcallero]

Hello @tasdienes , currently I am finishing up a proof of concept. Within the next 2-3 weeks I should have it finished. I know what I have to do I just need to implement it. Just needing to figure out a way to store the keytab for the proof of concept. After that I will be having to add more functionality to the gokerb library and figure out more implementation details.

[jgcallero]

@jefferai I have run into a snag and I want to know what would be the ideal solution for Hashicorp. Currently the only type of file that vault accepts is JSON. Kerberos tickets are not JSON, The only solution I can think of currently is to create an exception in the HTTP code for kerberos so it can accept tickets. If there is a better way to accomplish this I would be happy to implement it.

[jefferai]

@jgcallero I can't say as I have no idea what you are doing. I would recommend drafting an RFC describing what you propose to do, how, what the API will be like, and so on, before doing anything else.

[alv000h]

@jgcallero, I remember saw some people saving kerberos tickets as a "base64 string".

You should can serialize a kerberos ticket in base64 within a JSON object/text.

see examples here:
http://stackoverflow.com/questions/25289231/using-gssmanager-to-validate-a-kerberos-ticket
https://k5wiki.kerberos.org/wiki/Projects/Export_import_cred

[jgcallero]

Hey everyone, I finished a rough first draft of the RFC, after writing it I am unsure if my authentication method is the correct one. Is there anything in Vault stopping me from just asking for a kerberos ticket each time they try to use a command? I have pasted the RFC below

Draft_2.1.txt

Any changes that you think should be made I would be happy to discuss as well.

Edit: Updated to my latest version

[martin-ducar-gd]

@jgcallero I've gone through your draft as I'm interested to use this authentication method in the future. I have one concern. I don't understand why you need to store user keytabs in the vault. How we have implemented kerberos (using IPA) and I understand it to be common practice is that keytabs are secret and stay only on the place where the client is (so user keytab is stored only on users computer). kerberos supports service keytabs (they are stored on the server providing service) we are using it for apache see http://modauthkerb.sourceforge.net/configure.html, so you only need keytab for vault service that will contact either local keytab or KDC to verify user credentials. this way you don't need store for keytabs just the policy mapping. But maybe I just don't see you're proper reasons for it. Just my 5 cents.

[jgcallero]

@martin-ducar-gd Thank you for looking through the draft. The way I was understanding it was the keytab contains both user principles and encrypted keys used to decrypt tickets that are sent to the service. Doing additional research however tells me that you are right, and that I had the two concepts mixed up. The only thing that I need to store in vault is the service key, and storing the keytab within Vault is an unnecessary step and an unnecessary risk. I shall rewrite the RFC to accommodate that. Thank you again for pointing that out. I'll post a revised draft with that changed soon.

Edit:
Draft_2.2.txt
Here is the new draft

[jgcallero]

@jefferai I seemed to have missed messaging you when I got this draft for the RFC, I hope that it helps clarify what I was planning on doing. Given this RFC draft, I had two ideas once authentication has passed.

1. Have the user always send their ticket to be used as the Auth token, this way we can use the built in mechanisms of the lifetime of a kerberos ticket for their limited access.
2. When giving the client token the lifetime will be at minimum of what a client token should be or when the time of the ticket will expire.

Additionally given the way I understand Vault, it does not allow for Vault to request a kerberos ticket from the user after the HTTP API request has been sent, Should the user just attempt to send the ticket with the request or is there a way for Vault to request the ticket from the user after the API call has been made?

[jefferai]

@jgcallero Without even looking at the RFC, at a more fundamental level, I'm not sure how this would be implemented. One Golang kerberos library relies on cgo, which is a non-starter, and the other doesn't support modern security features.

[F21]

@jefferai Are there any plans to implement plugins for vault using something like https://github.com/hashicorp/go-plugin ?

Having a plugin architecture would allow others to easily implement secret and auth backends that are very specific to their use-case or backends that requires cgo.

[jefferai]

We have been evaluating it as well as the plugin support coming in 1.8.

[mbucc]

Jetty supports Kerberos. Would it work to wrap the vault API in a tiny Jetty service?

[mickenordin]

Could this implementation be used for this? https://github.com/jcmturner/gokrb5

[F21]

Since Vault now supports plugins, maybe it can be used to build a proof of concept for kerberos support.

[ah-]

We've built a simple plugin implementing kerberos auth, you can find it at https://github.com/wintoncode/vault-plugin-auth-kerberos

It's pure go using gokrb5.

There's some more discussion on implementation details here: https://github.com/hashicorp/vault/pull/3005

[simmel]

Oooh, awesome @ah- ! @mickenordin let's try this!

[jefferai]

Closing in favor of #3005 and the discussion going on there.