Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals
Hi Fraser, Martin and Alexander, Thanks for looking into this! For what it's worth, I think for this particular use case, I'm leaning more towards Alexander when he said: I don't think you need to group services this way. For managing services, and this means being able to issue certificates/keytabs for them, we have hosts. By default a host that a service belongs to is capable to modify userCertificate attribute of the service already, so I would expect it to be able to issue certificates with subject principal corresponding to the service. If CAACL would follow the same logic by allowing hosts that manage services to issue certificates with subject principals corresponding to these services, that should be enough because, after all, these host objects already have write permissions and can upload whatever certificates they like to the service objects. -- / Alexander Bokovoy Personally, I was very surprised when I discovered that, even though a host principal may manage a service principal, it is currently unable to request a certificate for that service principal if the service principal doesn't have specific access to the certificate profile, even though the host principal may have access to the same certificate profile. In my mind the CA ACL should be evaluated against the identity of the requestor, not the issuee. As long as the requestor is allowed to request on behalf of the issuee (achieved via the managedby attribute), then it should work. Now, if I used the credentials of the service principal directly (say, with a service keytab) to make the request (supposing the service principal wasn't listed in the CA ACL), then denying the request would be the expected behaviour (imo of course). Okay, so even though Alexander's suggestion might be more intuitive, implementing service groups might be more feasible from a technical standpoint, and I'm fairly sure this use case would also be solved by implementing service groups. But, it would be painful without automember regexp rules, so please don't forget this :D Cheers! On 2016-03-22 20:50, Fraser Tweedale wrote: On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote: On 03/22/2016 05:55 AM, Fraser Tweedale wrote: > On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote: ... > To my fellow FreeIPA developers: are service groups a sensible RFE? > Is there a reason why they have not been implemented? It *is* sensible RFE and it was actually already filed! https://fedorahosted.org/freeipa/ticket/5277 Please feel free to add yourself to CC to receive updates or even help us with implementation. Thanks, Martin Good to know... I've added myself to Cc and also filed an RFE for enhancing CA ACLs with service groups once #5277 is implemented: https://fedorahosted.org/freeipa/ticket/5753 Cheers, Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Certificate profiles and CA ACLs for service principals
Hi all, Firstly, a big thank you to everyone who works on the FreeIPA project - you guys are my heroes. Let's talk about the new Certificate Profile and CA ACL feature and some use cases that should be possible but I'm struggling to implement. Hopefully I'm just missing something obvious, and if not, perhaps someone here can suggest a workaround. I'll do my best to keep this as brief and concise as possible, and I'm grateful for any help given. Some background: Our environment is composed of AWS EC2 instances running CentOS 7 (7.2.1511 + ipa-server-4.2.0-15, fully patched afaik). Our instances acquire three certificates during creation, which is achieved via user-data/cloud-init. The first certificate is linked to service principal puppet/$HOSTNAME, the second is linked to HTTP/$HOSTNAME, and the third is the default NSS-based certificate linked to the host principal (via ipa-client-install --request-cert). We want our long-lived EC2 instances to acquire certificates using the standard caIPAserviceCert profile. Examples would be database servers, puppetmasters, etc. We use EC2 spot instances via auto-scaling groups heavily - these are our short-lived instances. For example, application servers, etc. We want our short-lived instances to acquire certificates with a really short validity (like 3 days). Read on to find out why. Our applications login to their respective postgresql databases using mutual SSL auth (i.e. IPA CA issued certificates). Sadly, postgresql has to be restarted every time the CRL is updated (see section 17.9.2 of postgresql doc). If the CRL expires, postgres stops authenticating clients via SSL. This means we're forced to either turn off CRL checking in postgres entirely or have really long CRL validity times - we're going to go with the latter. It also means application servers will need to be issued with short-lived certificates (and must not have access to the caIPAserviceCert profile) because we can't realistically restart our production database servers every time an application server's certificate gets revoked. The use case: 1. Suppose we have a hostgroup called "database_servers" and a host called "db01" that is a member. 3. Modify the default CA ACL "hosts_services_caIPAserviceCert" to restrict access to the "database_servers" hostgroup only (i.e. no services or users allowed). 4. Attempt to request a certificate (via ipa-getcert) from the "db01" server (which is in the "database_servers" hostgroup). The request should be linked (via -K) to a service principal like postgres/$HOSTNAME (service to be created beforehand). 5. This currently fails with CA_REJECTED ca-error: Server at https://ipa.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Principal 'postgres/db01.example@example.com' is not permitted to use CA '.' with profile 'caIPAserviceCert' for certificate issuance.). Is this the intended behaviour? If so, is there any way to avoid having to add each and every individual service principal directly to the CA ACL? After all, we have hostgroups to avoid the mess of adding individual hosts, right? Well... each host would have several service principals...and we don't seem to have a way of grouping them. Thanks in advance, ~earsdown -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
