On Tue, 24 May 2016, Petr Spacek wrote:
On 24.5.2016 09:44, Alexander Bokovoy wrote:
On Tue, 24 May 2016, Petr Spacek wrote:
On 24.5.2016 09:26, Alexander Bokovoy wrote:
On Tue, 24 May 2016, Petr Spacek wrote:
Speaking of certs, should we introduce a aliases for host entries to
avoid
the
need of fake hosts?
These 'fake hosts' are as good as aliases, even better, because they
allow us to have full control over who can manage them.


I do not see how this is different from any other object which has
managedBy
attribute. It is not a special property of host.
We have managedBy handling in hosts and services specifically to allow
certificate issuing on behalf of another entity.

I'm still not convinced that 'we historically do it this way' is good enough
justification for using fake host objects instead of tailored aliases.
I'm not sure it is good to add that. Note that host objects can be used
to provide a lot more than just mere aliases:
- they can have services associated, with both Kerberos keys and
  certificates
- they can be used to target HBAC rules against them which will be
  extremely useful when we'll get Authentication Indicators management
  in place

Having "fake" host objects is also crucial for clustered services.

Let me clarify this:
I'm not saying that we should drop host object completely.

I'm saying that 1 host should have exactly 1 host object + 0..n alises
pointing to the host object.

HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes
possible to automate things like 'get certificate will all associated names in
SAN' etc. without manual procedures.

This would make it easy to distinguish what is canonical name and what is mere
alias. That will get handy e.g. when a host is deleted - it would allow us to
delete all aliases with host etc.
The latter is the only benefit I see here, sorry. The rest is not giving
any real feature. If you want to have automated case for retrieving a
certificate with all dNSName records, we can add this one specifically
as an option to existing code to just follow managedBy -- CA has right
to ignore anything in the certificate request already and issue what it
thinks is right.

Alternative technical approach is to add aliases to an host's attribute and
use it from there. I suspect that this would be less flexible and less
future-proof.
I don't see a need for alias-as-a-property. Instead, I'm interested in
having a possibility to have different keys, certificates, etc, on
objects used as aliases. This improves security position by splitting
the manager and the user of the resource.

I think that these two are not mutually exclusive.

a) If you need separate keys (and the headache associated with it) use a new
host object.
b) If you need to share keys use alias.
Aliases could have other advantages, e.g. using diffrent DNS checks to the
user does not need to use --force just to create the alias.
Well, nothing prevents you from adding 'ipa host-make-alias' command that
would essentially create a host and set managedBy to a proper existing
host, and would use internally a different DNS check. This would be
trivial. Given that enrollment code expects there is already a
pre-created host object (or it will be created with enough privileges),
we can then use it in ipa-client-install to clearly express CNAME case.

Right now we do not have the (b) option so code needs to use hacks like the
one you proposed above:
"we can add this one specifically as an option to existing code to just follow
managedBy"

This is simply a hack and relies on user not forgetting to add option
--follow-managed-by (e.g.) when requesting a certificate. Not speaking about
automated processes requesting certs which would need own heuristics to detect
when the option should be supplied.
It is not an ad-hoc -- we already getting into situation that we have
three  different layers of permission checks on top of certificate
issuance -- managedBy to permit issuing a cert, CA ACLs to allow using a
specific certificate profile, and interpretation of cert request by CA.
Adding pure aliases into the mix is going to be 'interesting', while
making use of existing managedBy semantics is not complicating anything
here.

Don't also forget that people usually want to have aliases to allow use
of them by name at the edge -- i.e. in HBAC or SUDO rules. Adding an
alias concept means you'd need to make all of these (and HBAC/SUDO
aren't the only ones, actually) places to be modified, including client
software which is something you cannot change. To me aliases on objects
look like a huge pain.

If we want to have better management of co-related objects, then we
should improve the management, e.g. IPA framework. However, the objects
are there and their behavior expected to not change dramatically by the
client side.

I really do not like these ad-hoc hacks and I'm looking for a systematic 
solution.
The solution you proposed is actually asking for a systematic
reshuffling of all client pieces. This is not going to happen, sorry.

I'd like to come back to the original topic, though. Aside from security
consideration section which I'm going to add today, I need to add 'how
to use' section with clear sequenced instructions.

Dmitri also asked for a different type of deployment when the host is
enrolled into both IPA and AD with and without different names.
While it is a possible case, I don't think we want to promote it as to
do it correctly we need to have a perfect AD deployment. This is not the
case for majority of customer networks I've saw, and what's more
important, there is no real gain from such deployment.


--
Petr^2 Spacek

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to