"salting" names of service principals created by hdfs / hive when kerberos is enabled

[maxgruber19]

in case of using one ldap system for multiple environments like dev, int, prod the problem arises that service principals will be doubled when the cluster resource name and the namespace name is the same across those environments. even doing magic with multiple organisations won't solve the problem because principal names have to be unique within one domain.

we use the same namespace names in different environments (k8s clusters) and i really like that because it makes the platform way easier to use. going for namespaces with an environment suffix would do the job but maybe we can just modify the principal names at creation time.

i suggest adding an optional parameter principalSalt (for sure there is a better name) to secretclasses of kind kerberosKeytab

spec:
  backend:
    kerberosKeytab:
      realmName: CLUSTER.LOCAL
      kdc: krb5-kdc
      admin:
        mit:
          kadminServer: krb5-kdc
        # or...
        activeDirectory:
          # ldapServer must match the AD Domain Controller's FQDN or GSSAPI authn will fail
          # You may need to set AD as your fallback DNS resolver in your Kube DNS Corefile
          ldapServer: addc.example.com
          ldapTlsCaSecret:
            namespace: default
            name: secret-operator-ad-ca
          passwordCacheSecret:
            namespace: default
            name: secret-operator-ad-passwords
          principalSalt: dev
          userDistinguishedName: CN=Users,DC=sble,DC=test
          schemaDistinguishedName: CN=Schema,CN=Configuration,DC=sble,DC=test
      adminKeytabSecret:
        namespace: default
        name: secret-provisioner-keytab
      adminPrincipal: stackable-secret-operator

copied from https://docs.stackable.tech/home/stable/secret-operator/secretclass#backend-kerberoskeytab and modified

that should result in a principal like: dn/dev-hdfs.namespace.svc.cluster.local@CLUSTER.LOCAL instead of dn/hdfs.namespace.svc.cluster.local@CLUSTER.LOCAL

i thought about backwards compatibility for a longer time now and i think this should not be a big problem because no existing cluster is affected by that when the "salt" property is not set. i must confess that i have no clue about the consequences for hdfs or hive when the service principle name and the cluster service name don't match anymore.

[nightkr]

Hey,

Prefixing the principals probably wouldn't be great, since they're generally expected to match DNS FQDNs. Additionally, this would introduce a naming ambiguity (is the principal foo-bar for the service foo-bar, or the service bar with salt foo?).

Instead, I think the preferred way to go would be to use a separate KRB realm per environment, but I'm still trying to investigate how to do this without needing a whole dedicated AD DC per realm.

[maxgruber19]

Hi @nightkr, thanks for your fast answer. unfortunately I do not have the oppurtunity to use multiple krb realms per environment since I am forced to use one and only one realm.

Currently I only see the workaround of changing either cluster resource name or namespace name which feels anti-kubernetes somehow. Do you see a less anti-kubernetes alternative?

[nightkr]

After digging deeper, it looks like UPN suffixes would indeed be insufficient after all, since they don't affect service principal names. As I see it, there are three options available for this case:

1. Use a separate AD domain/realm for each environment (preferred, I know you already dismissed this for your environment, but included for completeness and future reference)
2. Use separate namespace names for each environment (prone to manual errors)
3. Use MIT Kerberos for testing environments (not great since it introduces a difference between the environments)

Of those, I'm afraid 2 seems like the least worst option for the scenario.

[maxgruber19]

We'll try solving by using "salts" in our cluster names of hive and hdfs. Namespaces would affect all the resources so we'll try to go the less invasive way. Thank you @nightkr for your fast answers.