Motivation
There is no coherent identity management plan for MOC 2.0. While RFC 01 identifies Keycloak as an IdP solution, it doesn’t discuss how Keycloak will be integrated into the MOC 2.0 environment.
Completion Criteria
Create Identity management plan
Description
Identity management covers more than just OpenShift clusters. In addition to controlling who can log into various OpenShift environments and what privileges they have, we also need to manage:
- Who can create resources in AWS (if we are using things like Route53 and Secrets Manager)?
- Who has permission to ssh directly into OpenShift nodes?
- Who has permission to ssh directly into non-OpenShift nodes?
- Who has permission to modify network switch configuration?
- Who is able to onboard new users into the environment?
There should be automated policies for all of these things, and they should be tied to onboarding/offboarding workflows so that people only have permissions for the duration of their tenure with the MOC.
Additionally, we need to plan for where Keycloak is hosted, and how that impacts service availability in the event of an outage (e.g., do we have a chicken-and-egg problem if Keycloak is hosted inside the “Infra” OpenShift environment?).
If we are relying on Keycloak as a single source of identity, will there be “break glass” accounts on various environments to permit administrative access in the event that Keycloak is unavailable? How will these account credentials be managed?
Completion dates
Desired - 2026-07-06
Required - TBD
Motivation
There is no coherent identity management plan for MOC 2.0. While RFC 01 identifies Keycloak as an IdP solution, it doesn’t discuss how Keycloak will be integrated into the MOC 2.0 environment.
Completion Criteria
Create Identity management plan
Description
Identity management covers more than just OpenShift clusters. In addition to controlling who can log into various OpenShift environments and what privileges they have, we also need to manage:
There should be automated policies for all of these things, and they should be tied to onboarding/offboarding workflows so that people only have permissions for the duration of their tenure with the MOC.
Additionally, we need to plan for where Keycloak is hosted, and how that impacts service availability in the event of an outage (e.g., do we have a chicken-and-egg problem if Keycloak is hosted inside the “Infra” OpenShift environment?).
If we are relying on Keycloak as a single source of identity, will there be “break glass” accounts on various environments to permit administrative access in the event that Keycloak is unavailable? How will these account credentials be managed?
Completion dates
Desired - 2026-07-06
Required - TBD