On ti, 19 kesä 2018, Peter Viskup via FreeIPA-users wrote:
Need to extend FreeIPA deployment into cloud environment (at the
moment we use it in our HQ only) and seek for options how to do the
deployment with keeping security in mind.
Have some questions:
- is it possible to configure FreeIPA replica for subtree?
No. All IPA objects are
equal -- each object subtree contains all
objects of that type so there is no difference in IPA users or groups,
all users are at the same level, all groups are at the same level too.
- not all FreeIPA accounts are required being available in cloud
environment (not all teams use clouds), would be great to be able to
limit amount of security objects being pushed to not controlled
environment
- is it possible to configure one way replica (HQ-to-cloud) with
possibility to register hosts on cloud instance?
Read-only replicas are not
supported. It is a much harder task to handle
and while we have been thinking about it for several years, other tasks
took over.
- what are best practices for FreeIPA deployment in dynamic
environment (e.g. in Kubernetes/Docker containers for DevOps)?
- how to properly register/unregister hosts/containers?
For FreeIPA 4.7 (to be
released soon) I added ability to have services
as group members and hosts can be registered even when there is no
corresponding DNS record for them. This makes possible to use Kerberos
services to represent containers and hosts to manage credentials
(keytabs) for them. Since these objects can be created/destroyed freely
and management of them can be controlled with groups, one can easily
use them for a dynamic container host management. We are not there yet
in OpenShift/Kubernetes but at least FreeIPA side is prepared to enable
people to achieve that.
- what is the implementation status of External Authentication
feature [1] (which might allow proper cloud deployment)
[1]
https://www.freeipa.org/page/V4/External_Authentication This is implemented
since version 4.5.0. Certificate-based
authentication is supported (see ipa-advise recipes for specific
configuration details). Other types of protocol transition would require
some additional configuration, like taking SAML token and instructing
mod_auth_gssapi which Kerberos principal to transit to. The latter also
assumes you have a certain IPA object existing already or ready to
pre-create it somehow.
We don't have a ready-made solution yet, though there is some effort on
allowing that in Keycloak. I have no details on the progress, though.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland