[Freeipa-devel] [DESIGN] Server Roles

[Martin Babinsky]

On 03/18/2016 02:44 PM, Petr Vobornik wrote:
> On 03/18/2016 10:59 AM, Martin Kosek wrote:
>> On 03/18/2016 10:47 AM, Martin Babinsky wrote:
>>> On 03/18/2016 10:21 AM, Martin Kosek wrote:
>>>> On 03/17/2016 06:16 PM, Martin Babinsky wrote:
>>>>> Hi list,
>>>>>
>>>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP
>>>>> design
>>>>> document concerning the concept of Server Roles as a user-friendly
>>>>> abstraction
>>>>> of the services running on IPA masters.
>>>>>
>>>>> The main aim of this feature is to provide a higher level interface
>>>>> to query
>>>>> and manipulate service-related information stored in dirsrv backend.
>>>>>
>>>>> I have not touched the design much from the post-Devconf session,
>>>>> mainly
>>>>> because there are some points to clarify and agree upon.
>>>>
>>>> Initial thoughts:
>>>>
>>>> * Use Cases: these are rather vague points what you want to
>>>> implement. In Use
>>>> Case section, I would like to see what specific *user* use cases you
>>>> are
>>>> addressing, i.e. what user problems you are solving. Ideally in a
>>>> form of a
>>>> user story. Like here:
>>>>
>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
>>>> or here:
>>>> http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
>>>> or here:
>>>> http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases
>>>>
>>> Ok I will thing of some clearer points.
>>>
>>>>> I have the following points to discuss:
>>>>>
>>>>> 1.) the design assumes that there is a distinction between roles
>>>>> such as DNS
>>>>> server, CA, etc. and the more specific sub-roles such as DNSSec key
>>>>> master, CRL
>>>>> master, etc. Now in the hindsight I think this distinction is quite
>>>>> artificial
>>>>> and just clutters the interface unnecessarily. We might implement
>>>>> this kind of
>>>>> hierarchy in the code itself but that is something the user needs
>>>>> not be
>>>>> aware of.
>>>>
>>>> Well, there are dependencies. A server cannot be a CRL master
>>>> without also
>>>> being a CA role. I assume same applies to DNSSEC master.
>>>>
>>>> I think we need to think more about distinguishing what is role,
>>>> what is just
>>>> an attribute of a role, etc. AD for example distinguishes roles,
>>>> role service
>>>> and features:
>>>>
>>>> https://technet.microsoft.com/en-us/library/cc754923.aspx
>>>>
>>> We will have to implement the role/subrole/unicorn hierarchy anyhow.
>>> What I
>>> would like to discuss is whether it is necessary to expose this
>>> hierarchy to
>>> the users. Consider a case when user wants to find which server is a
>>> CA renewal
>>> master:
>>>
>>> ipa server-role-find "CA renewal master"
>>>
>>> vs.
>>>
>>> ipa server-role-find --subrole "Renewal master"
>>>
>>> Behind the scenes, the code has to do the same thing (e.g. issue a
>>> search using
>>> (&(cn=CA)(ipaConfigString=enabledService)(ipaConfigString=caRenewalMaster))),
>>>
>>> but the UX is a bit different.
>>
>> Well, even the LDAP structure is different in this case. CA role is an
>> object
>> in cn=masters, caRenewalMaster is it's property. So they will likely be
>> different user objects too.
>>
>> For your example, I can image a search like that:
>>
>> $ ipa server-role-find "CA" --subrole "renewal-master"
>>
>> (for the case when you have "DNS" role also with "renewal-master"
>> sub-role).
>>
>> Martin
>>
>
> I don't have a strong option about this matter.
>
> Number of roles will be limited. I don't see any point in developing
> hierarchies in CLI/API/Web UI. Simply describing the roles and their
> dependencies in server-role help should be enough.
>
> Hierarchy and dependency should be checked internally.
>
> Question is how it should behave in practice. There is no example in the
> design page. Imagine these use cases:
>
> $ server-role-find
> "CA"
> "CA renewal master"
> "DNS server"
> "DNSSec Key Master"
> ...
>
> maybe is should print also description, but help might be enough.
>
$ server-role-find
===
Certificate Authority
Manages certificate requests and revocation...
(optionally list masters)
Enabled on: master1.ipa.test, replica3.ipa.test

===
DNS Server
manages forward and reverse name resolution
Enabled on: master1.ipa.test

===
CA renewal master
Manages automatic renewal of certificates nearing expiration
Enabled on: replica3.ipa.test
...

>
> $ ipa server-role-enable $SERVER "CA renewal master"
> Error: Server must have a "CA" role.
>
> $ ipa server-role-enable $SERVER "CA"
> Error: run ipa-ca-install on $SERVER to enable the CA role
>
> Note: if in future we implement a privileged daemon then the
> installation can be done by the daemon.
>
> # ipa-ca-install
>
> $ ipa server-role-enable $SERVER "CA"
> INFO: Server already in CA role
>
> $ server-show $SERVER
> ...
> Roles: DNS Server, CA
> ...
>
> $ ipa server-role-enable $SERVER "CA renewal master"
> SUCCESS: $server is now "CA renewal master"
> INFO: "CA renewal master" role was unset from $SERVER_PREVIOUS
>
> What is a purpose of `ipa server-role-disable`?
>
As an administrator I need to hide a misbehaving CA master from the 
topology so that CSRs are not forwarded to it. E.g.

'role_disable' can be also called internally when a 'singular' role 
(renewal master) is migrated to other master.
> If in future we need to configure a role then:
>
> $ ipa server-role-mod $SERVER $ROLE --fooattr=value (this is not
> supported in FW now because the attrs might differ based on $ROLE)


-- 
Martin^3 Babinsky