FreeIPA's Custodia instance ipa-custodia is a critical service. It has access to secrets such as CA's private key and 389-DS' directory manager. As of now, the service is protected in several ways

1. Requests and responses are transmitted over HTTPS, which gives us transport encryption and hostname verification.
2. Requests require valid Kerberos credentials
3. Requests are signed with the private JWK signing key of the requester and encrypted with the public JWK encryption key of the replication source server.
4. Responses are signed with the private JWK signing key of the replication source and encrypted with the public JWK encryption key of the requester.

In order to reduce the potential attack surface, point (2) should be limited to IPA servers instead of any user, service, or host. In case a severe flaw is found in the Python/jwcrypto/Custodia software stack, a limitation to members of the ipaserver host group would reduce the impact of such a vulnerability. Only IPA servers would be able to attack other IPA servers -- which is rather pointless.

AFAIK it is currently not possible to define a HBAC rule for this limitation. HBAC rules define which user is allowed to access combinations of services/service groups and hosts/host groups. Custodia does not have a distinct user but rather uses the host keytab to acquire a TGT.

Dependencies

The feature depends on#5277 to provide HBAC rules and HBAC service groups.

Steps

• add ipa-custodia PAM service with required pam_sss.so for account and auth
• Configure <Location "/ipa/keys/"> in ipa.conf to use mod_authnz_pam with AuthBasicProvider PAM and AuthPAMService ipa-custodia as explained at https://www.adelton.com/apache/mod_authnz_pam/
• configure SELinux bool setsebool -P allow_httpd_mod_auth_pam 1
• Add HBAC service ipa hbacsvc-add ipa-custodia
• Add service HBAC rule (#5277)