Perry Myers wrote:
The first pass at Matahari right now has zero auth on it, just a
username field to connect to a broker but no password. :)
Adam is working to add simple password auth to Matahari so that we have
some semblance of security.
But as Dmitri will point out, the real deal here is to get kerberos
integrated via IPA. Of course, qpid supports auth via kerberos, but
there are some practical matters we need to figure out.
Ignoring for a minute the issue of getting a machine its identity (which
Dmitri already covered separately), let's assume that the machine
already has a keytab file in place on the filesystem.
Ok, now we've got a keytab, but...
* How do we do the equivalent of kinit to load the identity and
authenticate to the KDC in an automated fashion? Kerberos tickets
generally have an expiration, so the 'kinit' would need to happen on
some sort of schedule? How is this done? (Note: crontab/at are not
good answers)
First I had to dig how it works in MRG/QPID/AMQP.
Here is the link:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Messagi...
If you look at item 3 :
1.
Make sure that each Qpid user is registered in the Kerberos
database, and that Kerberos is correctly configured on the client
machine. The Qpid user is the account from which a Qpid messaging
client is run. If it is correctly configured, the following
command should succeed:
$ kinit user(a)REALM.COM
So this implies that the machine is configured to be a member of the
Kerberos realm and user can authenticate with kinit.
In the sequence I am working on for bootstrapping we will have (my
script will provide) a machine kerberos principal, keytab and as a
result a TGT ticket. We do not need to renew since it is a one time
operation. But I do not have a clue on how to (or even if it is
possible) to tell the QPID client to use a specific principal other then
the current user.
Tedd can you please help with this?
For Matahari it is different since it would have to kinit internally
every time the GSSAPI failed becuase the ticket go expired. This is how
all applications do it. It looks like it should be something on top of
QPID becuase based on what I read on the page QPID client just assumes
that there is a ticket, so Matahari will have to implement this logic
itself. Fortunately it is a usual case for any client service and I
would be able to dig some example code quire easily. SSSD has to do it
for itself from time to time so we should have code there.
But before we even look into this we need to find answer to the question
above.
* Can/should we use keytab/identities that do not require a password
to
create a ticket? Since we need automation here, adding a password is
sort of self-defeating anyhow
Correct we should be using keytabs and host or service identities rather
than user identities. The challenge is to make qpid client respect that.
* What about Windows? If we're going to rely on Kerberos on
Windows as
well, that means we need to preinstall some MIT kerb software on
Windows which means we need to pull it into Fedora and cross compile
it along with mingw32-matahari? Or do we just say "if you want to
use Matahari/Kerberos on Windows, here go download this MIT kerberos
windows installer from http://...."?
Yes in the following ways:
a) We would have to port out ipa-join code to windows (not scheduled
right now)
b) This effort will automatically require kerberos libraries so we would
have to so it out and make sure we port all pieces needed, thus porting
this to windows would release you headache but add mine... I suspect
that QPID client on windows would leverage same libraries. If not then
we both got a problem to share :-)
* Aside from installing either ipa RPMS on Fedora or MIT kerberos
software on Windows, there's the issue of configuring your OS to use
a KDC. Do we just declare that that is outside the scope of Matahari
install and state "if you want to use Kerberos auth, first make sure
your OS has the proper software and configuration to connect to a
KDC"?
My thought is the following:
The first boot sequence will be Kerberized and will allow an newly born
VM to connect to the config server and pull first boot puppet script and
may be other bits of configuration . This puppet script or the
additional config info will have enough information to configure
Matahari to be a part of the IPA domain. Now here is an interesting
part. Which domain? It is not a bootstrapping domain. It should be a
part of the Cloud engine domain (or for the sake of security a separate
domain controlled by cloud engine but this does not matter for now). But
this domain is behind the firewall... So what you need to do? Right,
execute the VPN sequence first, get on the VPN and then using the data
provided by the bootstrapping server enroll with the right IPA using
pretty much the same client script that was used to enroll it in the
first place.
As alternative to VPN sequence we can use IEKERB - a special Kerberos
server that can be put into DNZ for access by clients outside the
firewall but we never tried it yet. It is a fairly new technology and it
is unclear whether it is fully baked or not. Implementing VPN sequence
IMO would be easier at least for now but I will drill down more on
IEKERB too.
Keep in mind that VPN sequence should be a part of every restart of the
machine to make it a part of the corporate infrastructure.
The problems to solve now are:
1) The client script I am working on with the subproblem of how to make
qpid client understand which principal to use. If we can tell it what
principal to use we might actually not need to rename a machine while
doing the enrollment magic.
2) VPN sequence - slides are on the list, we can talk about it next week.
Once these two things solved the problems of enrollment you rise above
will be solved.
Dmitri, thoughts? Just trying to figure out the practicalities of
making this easy to deploy and use for end-users on both Fedora and
Windows platforms.
Perry
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/