A host can support multiple host names. As such, the LDAP entry for the host can have multiple values:
Unfortunately, an admin user does not have the ACLs set up to do this. In order to run the following command:
dn: fqdn=ayoung-42.openstack.freeipa.org,cn=computers,cn=accounts,dc=openstack,dc=freeipa,dc=org changetype: modify add: krbprincipalname krbprincipalname: host/valid.openstack.freeipa.org@OPENSTACK.FREEIPA.ORG -
You need to run ldapmodify as "cn=Directory Manager"
So: to support, the API should support adding,removing kerberos principals from the user (can be done now with setaddr) and the ACLs need to be changed so that a user can edit the krbprincipalname value on the host record.
Polishing Description.
Related ticket: #3864.
Starting to shape next release
Worth mentioning why this feature is important. If there are multiple principals per host, you can user Kerberos based on the hostname of the machine, or based on other aliases. For a container based system like Docker or OpenShift, this means that a user can user Kerberos to authenticate when connecting to a container based on the container name, regardless of the hostname of the host machine
No, this is exactly the wrong case. If you have containers it is because you want isolation, so you want a different principal and key for the container. You do not want to share the same key material with the container.
If the container has a different name then the host name of the host is irrelevant, what matters is that "container-name" -> IP address ends up connecting you t a process running in the container.
As a correction: the reason for this request was for the internal/external naming of host; this is an OpenStack, not the Docker use case. The same machine may end up with two different IP address, a non-routable internal that comes up right away, and a routable external one. Both will get Hostnames, but each are likely in a different DNS domains. In order for securely authenticated access on both internal and external hostnames, both principals need to be accepted.
Replying to [comment:9 admiyo]:
Yes this is the valid use case, however I will point 2 possible workarounds that may be employed now, and in some cases are a better option: 1. Just use the same DNs name internally and externally, use DNS views to give back the right IP address depending on who's asking. 2. Simply create 2 host objects, one for the internal and one for the external name and get keys for both principals in the same keytab.
HTH
Replying to [comment:10 simo]:
Split-brain DNS is a pretty big PITA, and IMO is best avoided. When you want to address a specific interface and you have a route to both, you have to go looking up IP addresses, which defeats the point of having DNS in the first place.
This may be a workaround, but it definitely illustrates why this is a worthwhile enhancement.
Two points
The use case is not only OpenStack but Amazon too. In EC2 you do not control DNS so this is no t an option. There is a workaround that was crafted by OpenShift guys but it a workaround that needs to be solidified. http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html It describes the problem and the solution pretty well. This ticket is to make this happen.
About docker. Actually it seems that the direction this effort is going is that instead of having a container to do a stack of things there will be several containers that are configured to work with each other each of which represent a simple element. In this model one can deploy a container with SSSD that will server other containers, one will be say a DB, another app server and another web server. So the point here is that we can't assume that all that is needed for one application to work would be in one container under one host name. But let us table this use case for now. First one is good enough justification for the effort.
Is this maybe a duplica of #4421?
It seems like #4421 does describe the same phenomenon. Technically, that would be a duplicate of this ticket, as this one is far older.
FreeIPA 4.2.1 was released, moving to 4.2.x.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1117306 (Red Hat Enterprise Linux 7)
related: #3864
master:
ipapython/kerberos.py
Metadata Update from @admiyo: - Issue assigned to mbabinsk - Issue set to the milestone: FreeIPA 4.4
Login to comment on this ticket.