On 08/04/2011 01:42 PM, Mo Morsi wrote:
On 07/28/2011 07:04 PM, Dmitri Pal wrote:
> On 07/28/2011 06:51 PM, Mo Morsi wrote:
>> Some of these have been discussed, while some of these have been sitting
>> on my backlog for ages.
>>
>> -------------------
>>
>> Encryption:
>>
>> Currently configure allows us to generate ssl certificates for
>> conductor, we need to expand this to generate ssl certs for
>> imagefactory, iwhd, condor and deltacloud,
>>
>> Furthermore, AFAIK a cert creation resource type and provider is lacking
>> in the upstream puppet project. We can split these bits into its own
>> puppet resource type and provider and send that upstream for inclusion
>> into there.
>>
> IPA can give you the certs you need when you deploy the components.
> Certmonger also can help to automate provisioning.
>
> However I have not seen any follow up discussion on the wiki page I put
> together based on the meeting with Hugh that we had a month ago that
> describes the security between all the components of the solution.
>
In some senses we already are using IPA. We will be using the same LDAP
/ identity bits and are already using the same underlying cert
management tooling.
Since IPA pulls in alot of other things that we don't need, we should
hold off on total IPA integration until we do (IMO we shouldn't look for
a problem which we have a solution for)
If/when we do decide to incorporate it, it should be trivial to add the
IPA bits since we're using the same underlying tools
Sure. The only problem I see is that once you implement something like
SSL you are most likely not going to use GSSAPI or OAuth. The reverse is
true too. If you go with OAuth you are not going to implement SSL unless
absolutely pressed and you would try to move as far as you can with
whatever technology you picked making it even harder to change later on.
There is plenty of examples. Take Candlepin and BouncyCastle or Katello
and OAuth. They made the choice. They get issues but they try to
overcome them as solutions seem to be incrementally simpler than ripping
and replacing. So claims that we will integrate with IPA later and for
now we will use something simpler most likely would end up in more work
for everyone later as existing solution would have to be reworked
significantly or IPA would be tasked with new things that it currently
does not have capability of. The worst would be that the design choices
would be made that it would be impossible to switch. Think about openssl
and nss. NSS is certified and much more secure. It is preferred crypto
module but openssl is simpler. On multiple occasions use of openssl
created situations when it is impossible to switch to NSS as some of
things like revealing private key in clear are normal in openssl and a
no go in NSS. I want to avoid such decisions as much as possible.
>> -------------------
>>
>> Identity:
>>
>> Currently we use a users table in the db to store user identity. We need
>> to be able to integrate a user store from LDAP, whether it be a server
>> we setup ourselves via configure or an external one we integrate in
>> (both need to be supported)
>>
> IPA is your friend. We are working on the IPA VM so that it it can be
> easy to use and develop against.
>
In general I don't like requiring a VM to use / install aeolus (its fine
if its an optional feature). If we do, people with older system and/or
without a virtualization infrastructure can't use Aeolus.
-Mo
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/