search

kubernetes-csi / csi-driver-smb

This driver allows Kubernetes to access SMB Server on both Linux and Windows nodes.
Apache License 2.0
484 stars 130 forks source link

Kerberos ticket #512

Open kandolfp opened 2 years ago

kandolfp commented 2 years ago

Would it be possible to not go for username and password but to use a Kerberos ticket for the mount instead?

It would be the equivalent of a mount on the host as: //server/share /mnt cifs multiuser,sec=krb5,user 0 0

Users will have access to it after a kinit to get a kerberos ticket. Equivalently the pod would need a kerberos ticket but that could be provided by an init script.

andyzhangx commented 2 years ago

so what's the mount options in this case?

kandolfp commented 2 years ago

the options above are multiuser,sec=krb5,user this way the mount uses kerberos and it separate per user. So if the drive is mounted but your users has no kerberos ticket you will not be able to access it.

get a ticket with kinit and you can access it.

It just exchanges user, passwd with a kerberos ticket. the ticket would be generated in the pod.

avishefi commented 2 years ago

Working with Kerberos also solves working under FIPS since NTLM-based SMB requires hmac-md5.

shaunrampersad commented 1 year ago

@kandolfp did you manage to get this to work with Kerberos? If so, how did you do it?

My issue is as @avishefi states, the cluster is installed with FIPS enabled so NTLM wont work.

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

yrro commented 1 year ago

the options above are multiuser,sec=krb5,user this way the mount uses kerberos and it separate per user. So if the drive is mounted but your users has no kerberos ticket you will not be able to access it.

Not sure what user means here. Isn't it the option used to specify username? It's probably just redundant when multiuser is specified.

In this mode, when a process tries to access a share, the kernel makes a cifs.spnego upcall to request encryption keys.

It's not clear how this can work when the process triggering the upcall is running in a container. I found a linux-security-module mailing list thread proposing changes to make it work smoothly but I don't know if it was adopted.

andyzhangx commented 1 year ago

for Kerberos ticket support, it requires agent node domain join first, here is one example: https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-nfs-clients#ubuntu-configuration

andyzhangx commented 8 months ago

since this feature is already implemented by this driver, when the kerberos ticket is expired, how does this driver handle this issue? do we need to unmount the pv and mount again?

yrro commented 8 months ago

I think the existing Kerberos support is a little bit incomplete. As a user I would like to put a keytab into a secret and have that be used to authenticate the mount; I don't want to have to manage a directory of credentials cache files on every node...

avishefi commented 8 months ago

@yrro take a look at: https://github.com/kubernetes-csi/csi-driver-smb/blob/master/docs/driver-parameters.md#pass-kerberos-ticket-in-kubernetes-secret

yrro commented 8 months ago

"To pass a ticket through secret, it needs to be acquired" - there's the problem. The tickets in a credential cache expire within a few hours.

What I'd like as a user is to have csi-driver-smb handle obtaining the ticket automatically. To do this, a long term secret (in the form of the user's Kerberos keys stored in a keytab file) are required. I'd like to provide the keytab file to csi-driver-smb via a secret object. The mount performed by csi-driver-smb would use the sec=krb5i option.

The difficultly comes when the kernel makes the cifs.spengo upcall in order to obtain Kerberos keys. csi-driver-smb would have to service this upcall, and at that point it would need to use the keytab to obtain a TGT, and then use the TGT to obtain a ST and return that back to the kernel (I'm handwaving here, but hopefully that makes sense to someone who knows how kerberos-authenticated SMB mounts on Linux is implemented).

cccsss01 commented 8 months ago

I'd like this feature as well

k8s-triage-robot commented 5 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 4 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

yrro commented 4 months ago

/remove-lifecycle rotten

k8s-triage-robot commented 1 month ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 2 days ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

yrro commented 1 day ago

/remove-lifecycle rotten