4:02 p.m.
On 7/2/2014 12:17 PM, Ade Lee wrote:
The problem with the above proposal is one of migration. Customers
are
used to both creating new profiles and modifying existing profiles to
suit their needs. If we go along with this mechanism, we would have to
tell these customers that they would need to rename their existing
customized profiles (and update all the relevant clients etc.)
Just to clarify, so there are 3 proposals:
1. Stacked profiles (Fraser's proposal)
2. Pure LDAP profiles (Ade's proposal)
3. Separate file/LDAP profiles (my proposal)
As discussed over IRC, proposal #3 will be supplemented with a mechanism
to allow creating aliases for backward compatibility. I'm trying to
generalize the mechanism to become "profile inheritance".
Basically each LDAP profile will have an optional parent. The parent can
be the file-based system/default profile, or another LDAP profile. A
sub-profile will inherit all attributes, except when it's explicitly
declared in the sub-profile. This mechanism allows us to create just a
proxy/alias, a full clone, or anything in between. For example, a proxy
profile might only have a few attributes:
dn: cn=caAdminCert,ou=Profiles,ou=CA,{suffix}
objectClass: certProfile
cn: caAdminCert
parent: defaultAdminCert
visible: true
Let's say in the old system we have an unchanged caAdminCert and a
customized caUserCert. With proposal #1 we'll have:
1. caAdminCert (file)
2. caUserCert (LDAP)
3. caUserCert (file, inaccessible via REST due to the LDAP entry)
With proposal #2 we'll have:
1. caAdminCert (LDAP)
2. caUserCert (LDAP)
3. caAdminCert (file, for initial installation only)
4. caUserCert (file, for initial installation only)
With proposal #3 we'll have:
1. caAdminCert -> defaultAdminCert (proxy)
2. caUserCert (LDAP)
3. defaultAdminCert (file)
4. defaultUserCert (file)
The benefits of proposal #3 are:
1. The system/default profiles will be stored in /usr/share/pki. People
will be naturally discouraged to change them since it will be
overwritten during RPM upgrade. On the other hand, an LDAP profile,
although we can flag it as system profile or make it read-only, is more
tempting to change.
2. The original/unchanged system profiles will be accessible via REST as
well so people can use it directly and rely on auto update.
3. Backward compatibility can be maintained with proxy profiles. These
profiles will be updated automatically during RPM upgrade since it's
pointing to the file-based system profiles. No need to write upgrade
scripts.
4. The proxy profiles can be used to hide certain system profiles
without creating a full clone. With stacking, to hide caAdminCert we
probably would have to create a full clone then change the visibility,
and lose the auto update ability.
5. The mechanism can be used to extend/change the behavior of the
default profiles without having to create the full custom profile. For
example we want to create IPA-specific caUserCert with different inputs.
In this case we'll be able to just create a sub-profile with the new
inputs. No need to clone the entire profile.
There is another problem, and that is that it is not clear that we
want
updates to the default profiles to be propagated to existing instances.
I have looked at the profiles and there have been only a handful of
changes over the last 7 years. Those changes include things like
updating the default signing algorithms or the default validity. More
likely than not, admins would prefer that we not change the behavior of
profiles in existing instances underneath them.
The changes that I have found are all behavioral - and therefore things
that admin can opt out of -- or would prefer to do on their own
schedule. There have been no structural changes.
If there are structural changes, then we need to (and can) provide an
upgrade script which would run with the automatic upgrade. An example
of this would be a schema upgrade as we sort out how to represent
profiles in LDAP.
As discussed, we're separating database changes into:
1. structural changes (e.g. schema change, adding/removing attributes)
2. behavioral changes (e.g. changing SHA1 to SHA512, default validity)
The structural changes will be semi-automatic. The admin decides when to
run them, but it's not necessary to review them one-by-one. The
behavioral changes should be reviewed by a security expert to make sure
that it won't affect their particular system negatively.
With proposal #3 the admin can decide whether to (a) trust us
(developers) to make the behavioral changes automatically by using the
default profiles directly or using proxy profiles, or (b) maintain a
full control of all behavioral changes using custom profiles. If all
profiles are in LDAP they might be limited to option (b) because the
upgrade script won't be able to tell whether the current value is a
default value that we can change, or it was intentionally set by the admin.
--
Endi S. Dewata