Give the ability in VaultSharp to conveniently feed it the krb5.conf and keytab files like we do for CLI Login

[michvllni]

Describe the feature request or question A clear and concise description of what the problem is. Where do I have to place my kerberos config file for vaultsharp to use it when authenticating via kerberos? Is there a way to pass this to the KerberosAuthMethodInfo? Additional context When trying to authenticate via kerberos I'm unsure where my kerberos config is supposed to be placed (windows client, linux server)

[michvllni]

The workaround for me was to add an additional encryption tab to my keytab to match the default one. Nontheless it would be nice if it was possible to pass a kerberos config file in the same way as when logging in via vault CLI

[rajanadar]

Hi @michvllni

Let me look into this this weekend and get back to you.

[rajanadar]

still working on this @michvllni

[rajanadar]

the aim of vs is to avoid file reading on client machines. THis is because problems arise due to local permissions, windows vs mac vs linux, desktop vs test env vs prod env and so much more.

The expectation is for host apps to read the file and provide the data as clear fields to the library settings. Let me know if anything specific is missing that way.

[michvllni]

@rajanadar I understand this. I have no issues with reading the content and providing it. But which field does accept the krb5 config?

[rajanadar]

This is an interesting issue.

A Kerberos login involves you to do 3 things:

1. Configure Vault with Kerberos Config. This is where you configure your keytab file with Vault
2. Configure Vault with Kerberos LDAP Config. This is where you configure the ldap service account, password etc.
3. And Finally do the kerberos login as a client. This is where the SPNEGO Token is generated and validated.

The first 2 steps are administrative APIs in Vault (done outside of an application) via /auth/kerberos/config and /auth/kerberor/config/ldap endpoints.

The 3rd step however, is itself a 2 step process.

3.1. Using the krb5 config contents to generate the spnego token 3.2. And then send this token to vault for kerberos login.

So basically, leaving aside the administrative config steps 1&2, it looks like VaultSharp is currently doing 3.2, and leaving 3.1 to the host app. VaultSharp as of today expects the final credential to be provided, and leaves the generation of the credential to the host app.

And your ask is, "You don't mind reading the krb5 file contents and feeding the contents to VaultSharp, but let VaultSharp do step 3.1 for convenience". Is that a fair takeaway?

[rajanadar]

meanwhile i'll learn more about Kerberos this week @michvllni . i know its an involved tech if you want to get into the krb5, sp token etc.

[michvllni]

Yes, this is what I meant. This is also what I meant with my first comment which basically solves the 3.1 step but I thought it would make sense if vaultsharp worked the same way as the vault CLI here

[rajanadar]

understood. i'll read up more and see if it makes sense to get cli parity at that level with VaultSharp.

Currently, if you pass ICredential (NetworkCredential with domain, username & password OR DefaultCredentials) into the existing VaultSharp mechanism, are you encountering issues?

[michvllni]

so far I've been using default credentials because I wanted to prevent storing credentials in my automated processes, this is what I use vaultSharp for

[rajanadar]

Even for credential based access, VaultSharp won't retrieve actual passwords, it has to be provided into it.

What scenario is not working for you?

[michvllni]

Yes I know that, but I will have to provide the credentials outside vaultsharp (within my application code) which is what I want to prevent.

[michvllni]

This is what I'm using:

//Initialize Vault Client
IAuthMethodInfo authMethod = new KerberosAuthMethodInfo();
var vaultClientSettings = new VaultClientSettings(vaultUrl, authMethod);

IVaultClient vaultClient = new VaultClient(vaultClientSettings);
vaultClient.V1.Auth.PerformImmediateLogin();

string secretName = "mySecret";
string mountPoint = "myMount";
Secret<SecretData> kv2Secret = vaultClient.V1.Secrets.KeyValue.V2
                   .ReadSecretAsync(path: secretName, mountPoint: mountPoint).GetAwaiter().GetResult();
_clientId = kv2Secret.Data.Data["clientId"].ToString();

It would be good if it was possible to pass either a file path or a string containing the config to the IAuthMethodInfo authMethod = new KerberosAuthMethodInfo(); constructor

[rajanadar]

understood. let me study what the vault kerberos plugin go code does and get that convenience replicated for you. Give me a couple of days, i'll update on the next steps.

[rajanadar]

cool. i studied the vault cli go code for how it handles kerberos login with all those files as input. i understand.

it does a lot of convenience things (using gokrb5 helper kerberos go package) to read the files, interpret them, use them to get the spnego token and then finally the vault token. The helper package provides all the keytab and krb5 config file handling and value interpreation thing.

@michvllni I'll create the equivalent in VaulrSharp (C#) using .NET Kerberos helper libraries (or if none, write the parsing myself) and give you one of two things.

1. Either the convenience baked into VaultSharp (i will evaluate if dependencies are worth it for all VS users)
2. OR Give you a helper class as a Gist that'll produce what VS needs as input in KerberosAuthMethodInfo, that you can use and do no work on your side.

1 is my preference. I'll update you in a week with the progress.

Thanks for the engagement

[rajanadar]

@michvllni I have written a helper method here. can you please try this in your environment and see if the method gives you a valid spNegoToken? (Take a nuget reference of Kerberos.net before using the class)

The helper method will accept your keytab and krb5config file paths and do all the stuff internally to give you a valid spnego token. Since I don't have a Kerberos setup to test this out, please let me know if you can generate the token successfully. If you can, then what i can do is, add the ability in VaultSharp to accept this spnego token in KerberosAuthMethodInfo and generate the Vault token. The helper class can be something Kerberos based VaultSharp users can benefit from. It'll keep the size/dependencies of VaultSharp minimal.

https://gist.github.com/rajanadar/28c86d967695262bfe1f17ae82fb3d3d

[rajanadar]

in fact @michvllni , using the above gist, you can generate the spnego token and then use VaultSharp's

vaultsetting.BeforeApiRequestAction to actually add the token to every outgoing request and see it working for yourself.