Support Kerberos authentication

[spilchen]

This adds support for Kerberos authentication over HDFS.

A few new fields were added to the CRD to support Kerberos:

• spec.kerberosSecret: This will mount Kerberos files in the Vertica container. It takes the name of a secret. The secret must have the following keys:

  • krb5.conf: The contents of the Kerberos config
  • krb5.keytab: The keytab file that stores credentials for each Vertica principal (i.e. each vertica host).

  These files will be mounted in /etc.

  We use the same keytab file on each host, so it must contain all of the Vertica principals.

  This property does not live under spec.communal because it can be used for general setup of Kerberos authentication.

• spec.communal.kerberosServiceName: The service name portion of the Vertica Kerberos principal. This is set in the database config parameter KerberosServiceName during bootstrapping.

• spec.communal.kerberosRealm: Name of the Kerberos realm. This is set in the database config parameter KerberosRealm during bootstrapping.

Putting this all together, here is a sample CR that creates a database using HDFS for communal with Kerberos:

apiVersion: vertica.com/v1beta1
kind: VerticaDB
metadata:
  name: sample
spec:
  communal:
    path: "webhdfs://hdp31ns/verticadb"
    hadoopConfig: hdfs-conf
    kerberosServiceName: verticadb
    kerberosRealm: EXAMPLE.COM
  kerberosSecret: krb5
  subclusters:
    - name: sc1

The vertica engine has a requirement that the keytab file be readable and writable by dbadmin, and is not accessible by any other group or user. And in k8s it isn't possible to mount a Secret for a specific user. In order to satisfy the engine's requirements, we use an initContainer to copy the keytab so we can get the correct permissions of the file. This has the downside that the pod would need to be restarted if the keytab ever changes.

When setting up the krb5.conf file, it is important to add to the 'domain_realm' section a mapping of the Kubernetes cluster domain to the realm. For instance, by default Kubernetes cluster have a domain of '.cluster.local'. If the Kerberos realm that you have setup is EXAMPLE.COM, the domain_realm section should have something like this:

[domain_realm]
  .cluster.local = EXAMPLE.COM

[roypaulin]

looks good. But do you mind giving more details about it? just to know a little bit about the steps that led to that