GSSAPI Authentication mapping of system usernames to database names

[data-matt]

Is your feature request related to a problem? Please describe. In kerberos GSSAPI secured deployments, accounts can exist in multiple domains(realms), eg: user1@domain1.com user1@domain2.com

In the current implementation of kerberos in cockroachdb the domain is stripped away as gssapi usernames are not currently able to be mapped to database usernames, see: https://www.cockroachlabs.com/docs/stable/gssapi_authentication.html

Which includes this quote: "The include_realm=0 option is required to tell CockroachDB to remove the @DOMAIN.COM realm information from the username. We do not support any advanced mapping of GSSAPI usernames to CockroachDB usernames right now."

We have requirements to be able to demonstrate control over which domain account is being used to login to a cluster. Currently we are not able to evidence which domain instance of an account is logging in to a cluster, eg: user1@domain1.com exists in a cockroach cluster simply as database username "user1"

if user1@domain1.com is approved for access to a cockroach cluster, but user1@domain2.com is not, user1@domain2.com is ticket and subsequently authenticate and access the database cluster as cockroachdb is currently ignoring the @domain part of the system username.

Describe the solution you'd like We need cockroachdb to support include_realm=1 so that we can enforce and audit upon which accounts in which specific domains are entitled and logging in to each database cluster.

Describe alternatives you've considered Complicated hba.conf mixed with mapping rules per user.

Additional context Add any other context or screenshots about the feature request here.

Jira issue: CRDB-20739

gz#14443

[knz]

@data-matt can you elaborate on the alternative you've considered, and why it wasn't sufficient?

[data-matt]

Hi @knz,

The issue is, if you have a map for USER1@DOMAIN1 and another map USER1@DOMAIN2, if you come in as USER1@DOMAIN2, but hit map USER1@DOMAIN1 as its the first in the map, then you are rejected access.

so for example we have hba.conf like so:

host all all all map=specific host all all all map=everyone

identity_map.configuration specific USER1@DOMAIN1 USER1 everyone /(.*)@DOMAIN2 \1

We was hoping, USER1@DOMAIN2 to be able to connect when they hit the everyone rule, however I believe that the first rule, USER1@DOMAIN1 USER1 is rejecting USER1@DOMAIN2.

Is there something we are missing? I hope so

[knz]

To solve this, you will need the patch in #94915 . Once this patch is applied, then here is the way to configure this:

• in hba.conf use host all all all map=combined
• in identity map:

combined USER1@DOMAIN1 USER1
combined /(.*)@DOMAIN2 \1

This way both user1@domain1 and user1@domain2 can log in as SQL username 'user1'.

Does this solve the problem?

[data-matt]

Interesting, it looks good to me!

Can we backport?

Will review with our customer :)

[knz]

we'll discuss backport when the patch is ready. (it's not yet)

[data-matt]

The final consideration we have around this is the maximum amount of mapping rules we can implement before it impacts performance?

[knz]

the maximum amount of mapping rules we can implement

There are two numbers:

• the number of separate maps, which is the number of unique values in the first column
• the maximum number of rules per map, i.e. the number of lines that have a common value in the first column.

Login latency is proportional to the 2nd number. The first number (number of maps) should not matter much.

I believe (based on casual experiment) that a mapping with less than a few hundred rules should result in very low login latency overhead. Above this number, it may not be trivial any more.

With a large number of rules (tens of thousands or more), memory usage may also become an issue.

[knz]

@data-matt as you've discovered, the change in https://github.com/cockroachdb/cockroach/pull/90439 offers something that appears like it's what you want: domain match on the username column of the HBA configuration.

So maybe you can use this HBA config:

host all all user1@domain1 map=specific
host all all all map=everyone

which will make the 1st rule apply just for that user, and the 2nd for everyone else.