69 lines
2.7 KiB
ReStructuredText
69 lines
2.7 KiB
ReStructuredText
Authentication in Communishift
|
|
==============================
|
|
|
|
Resources
|
|
---------
|
|
|
|
- https://docs.fedoraproject.org/en-US/infra/ocp4/sop_configure_oauth_ipa/
|
|
- https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/ipsilon/#_create_openid_connect_secrets_
|
|
|
|
Discussion
|
|
----------
|
|
|
|
Would it be possible to have groups in Openshift linked to groups in FAS. Having a
|
|
central place to control group access would make authentication easier and more
|
|
transparent.
|
|
|
|
Identity provider
|
|
-----------------
|
|
|
|
The cluster was linked to the Fedora account system as a necessary precursor to the
|
|
investigation.
|
|
|
|
An openid secret was created in the private ansible repo using the `openid connect SOP
|
|
https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/ipsilon/#_create_openid_connect_secrets_`
|
|
The ipsilon playbook was then run to provision the secret.
|
|
|
|
To configure openshift this `SOP
|
|
<https://docs.fedoraproject.org/en-US/infra/ocp4/sop_configure_oauth_ipa/>`_ was follwed
|
|
to add an oauth client to allow access to the cluster.
|
|
|
|
Group access
|
|
------------
|
|
|
|
Ideally we would like to be able to map groups from IPA to Communishift as this would
|
|
make adding and removeing users from projects easier to manage.
|
|
|
|
Openshift supports group integration with ldap servers, ipa is an ldap based server
|
|
however it was deemed not secure to allow an external application have access to our
|
|
internal ipa server.
|
|
|
|
Openshift also supports group mapoping from openid clients which would be the preffered
|
|
course of action for us as we are using ipsilon anyway. However this is not yet
|
|
supported in Openshift Dedicated. OSD support have said there is an RFE for this to be
|
|
added but the ticket is private internally so we cannot track progress on it.
|
|
|
|
Conclusion
|
|
----------
|
|
|
|
As the supported solutions are not suitable it would be necessary to create a custom
|
|
solution to carry out group mappings. This could be in the form of an openshift
|
|
operator, a toddler or an ansible script run on a cron job.
|
|
|
|
Namespaced groups would need to be created in IPA such as communishift-<project> and the
|
|
users added with a sponsor for each group. These would then need to be automatically
|
|
replicated in Communishift
|
|
|
|
A possible skeleton solution would be to:
|
|
|
|
- Periodically call fasjson for any group that begins with communishift- (but not
|
|
**communishift** as this already exists and is separate).
|
|
- Get the list of users for that group
|
|
- Check if the group exixts in openshift and create if not
|
|
- Check the list of users in fasjson against the list in Openshift and add/remove if
|
|
necessary.
|
|
|
|
Optional:
|
|
|
|
- Get the list of sponsors for the group in fasjson and use these to set rbac permission
|
|
levels of admin and all other members of the group have basic user access
|