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
|