CNAME record leaks into juju's private-address, breaks host based access control

[Andreas Hasenack]

Mailing list thread, for reference: https://lists.launchpad.net/maas-devel/msg01375.html

Some charms use the relation value "private-address" to set host based access controls. Postgresql, for example, uses this value for the pg_hba.conf line like this:

host all all kmkxr.maaslocal md5

In the case of MAAS, that value is the CNAME record for that host:
# host kmkxr.maaslocal
kmkxr.maaslocal is an alias for 10-0-5-100.maaslocal.
10-0-5-100.maaslocal has address 10.0.5.100

And this breaks the access control:
2013-11-07 13:47:02 UTC FATAL: no pg_hba.conf entry for host "10.0.5.100",
user "landscape", database "landscape-standalone-main", SSL off
2013-11-07 13:47:02 UTC DETAIL: Client IP address resolved to
"10-0-5-100.maaslocal", forward lookup not checked.

It's also how openssh behaves. If you setup a key in authorized_hosts to only accept connections from a specific hostname, this is what happens:

Nov 11 11:45:49 wfaxq sshd[2332]: Authentication tried for ubuntu with correct key but not from a permitted host (host=10-0-5-103.maaslocal, ip=10.0.5.103).
Nov 11 11:45:49 wfaxq sshd[2332]: Connection closed by 10.0.5.103 [preauth]

/home/ubuntu/.ssh/authorized_keys:
from="k8q9m.maaslocal" ssh-rsa AAAAB3NzaC1yc2EA...

# host k8q9m.maaslocal
k8q9m.maaslocal is an alias for 10-0-5-103.maaslocal.
10-0-5-103.maaslocal has address 10.0.5.103

As long as the CNAME record is what shows up in juju's private-address, these types of access controls won't work. It doesn't happen with the AWS, LXC and OpenStack providers (didn't test others).

Some options were briefly discussed:
a) Drop the CNAME entirely and keep the generated A and PTR records only
b) Keep the CNAME, but use the A record for the private-address (and probably the actual $(hostname -f) of the unit)
c) Drop the CNAME and use the "friendly" name for the A record

Possibly others I forgot.

[Julian Edwards (julian-edwards)]

Escalated by Dean.

[Andres Rodriguez (andreserl)]

Andreas and I found out that the use of socket.gethostbyname should be enough to fix this in the charm.

[Andreas Hasenack (ahasenack)]

I filed bug #1276807 to use socket.gethostbyname() in the postgresl charm.

[Julian Edwards (julian-edwards)]

On Wednesday 05 Feb 2014 17:16:22 you wrote:
> Andreas and I found out that the use of socket.gethostbyname should be
> enough to fix this in the charm.

OK. We're going to change maas anyway, as this will trip people up.

[Raphaël Badin (rvb)]

We've dropped the CNAME records. The private-address is now an A record.

Forward zone:
hostname → (A) → IP

Reverse zone:
IP → (PTR) → hostname

[Yaguang Tang (heut2008)]

Is it possiable to backport this fix to current MaaS 1.5.2 in trusty ? This is required for rabbitmq-server charm to works well in active/active clusteing mode.

[Julian Edwards (julian-edwards)]

On Wednesday 23 Jul 2014 07:25:34 you wrote:
> Is it possiable to backport this fix to current MaaS 1.5.2 in trusty ?
> This is required for rabbitmq-server charm to works well in
> active/active clusteing mode.

That's not going to happen because 1.6 is being released soon, which should
get uploaded to trusty.

[Edward Hope-Morley (hopem)]

@julien-edwards no sign of 1.6 or this patch in trusty yet. Is it still planned for 1.6 to be released for trusty? If not can this patch be backported to trusty?

[Julian Edwards (julian-edwards)]

1.6 is not going to be uploaded to any Ubuntu release, please look out for 1.7 in Utopic. 1.7 *may* be backported to Trusty but it depends on ongoing techboard approval.