FIPS enabled images break azure-file storage class

[kwoodson]

With the recent updates to the vm image and enabling FIPS mode in the kernel the CIFS mounts have stopped working.

After searching through logs and manual attempts to perform the mount I discovered this in the logs:

Jul 02 19:09:23 compute-1562081346-000000 kernel: CIFS VFS: could not allocate crypto hmacmd5
Jul 02 19:09:23 compute-1562081346-000000 kernel: CIFS VFS: could not crypto alloc hmacmd5 rc -2
Jul 02 19:09:23 compute-1562081346-000000 kernel: CIFS VFS: Error -2 during NTLMSSP authentication
Jul 02 19:09:23 compute-1562081346-000000 kernel: CIFS VFS: Send error in SessSetup = -2
Jul 02 19:09:23 compute-1562081346-000000 kernel: CIFS VFS: cifs_mount failed w/return code = -2

A quick internet search brought back multiple articles responding to the inquiry:
https://access.redhat.com/solutions/256053

It appears that ntlm uses md5 hashes which are not supported under FIPS mode. The only supported mode is sec=krb5. I'm not sure enabling krb5 is possible when using the storage class.

Doc: https://kubernetes.io/docs/concepts/storage/storage-classes/#azure-file

This includes mount options but I'm not sure how we could hook up kerberos for the storage class:
https://github.com/feiskyer/kubernetes-handbook/blob/master/en/troubleshooting/azurefile.md

[kwoodson]

@jim-minter @mjudeikis @ehashman @kad WDYT?

Should we disable FIPS at this time?

[ehashman]

I'm not sure enabling krb5 is possible when using the storage class.

As someone who has run kerberized mounts in production, we don't want this (and I don't think we have the necessary infra set up right now to make it happen).

I'd be okay with rolling this back for now to unblock things, and possibly permanently. We should confirm with some folks for security whether or not we need FIPS support. Interestingly, I found an article from MS TechNet that removed a recommendation to use FIPS mode in 2014.