Sam Morris via FreeIPA-users wrote:
I'm looking into using
<
https://github.com/guilhem/freeipa-issuer> to
request certificates from FreeIPA on behalf of a (FreeIPA) service.
The project authenticates to the FreeIPA API with a specified username
and password:
<
https://github.com/guilhem/freeipa-issuer/blob/174d145616a672b09d3fdb56b2...
I presume this means that it's only possible for it to authenticate to
the FreeIPA API as a user, as opposed to a host or service.
That being the case, I am trying to lock things down as much as
possible, so that the user is only able to request certificates for a
single service.
I've had a read through Fraiser's excellent blog post
<
https://frasertweedale.github.io/blog-redhat/posts/2015-09-02-freeipa-cer...
which points me towards creating a CA ACL, which I've done.
The CA ACL links together the user, the service and for good measure I
specified the CA and the profile too. But it's not sufficient to allow a
certificate request to work, as when the issuer tries to ask for the
certificate:
Fail to request certificate: ACIError (2100): Insufficient access:
not allowed to perform operations: request certificate
Returning to the blog post, I gather I additionally need to grant the
following two permissions to the user:
* 'Request Certificate'
* 'System: Modify Services'
What I'd like to understand is the scope of these permissions.
Does 'Request certificate' merely unlock the ability to make requests
that are themselves constrained by CA ACLs? That being the case, this
permission alone doesn't let the user request certificates for any other
hosts or services, right?
It's an on/off whether you can request certificates at all. Other
controls are expected to handle who can request what.
As for 'System: Modify Services': I guess granting this
permission will
allow the user to add certificates to *any* service? In which case, I
suppose I need to create a new privilege that allows the usercertificate
of a particular entry only to be modified. Are there any examples of
this?
System: Manage Host Certificates is probably a better template.
I don't believe there is a current permission that limits by host.
You'll want to set a target. Since Kubernetes is the base you should be
able to control the hostnames so you could use an automember rule to put
them into a specific hostgroup and set the target to that.
rob