Kerberos ticket

[kandolfp]

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]

so what's the mount options in this case?

[kandolfp]

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]

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

[shaunrampersad]

@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]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[yrro]

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]

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]

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?