OIDC resiliency

We aim to solve for both regional resiliency of OIDC provider keys that live in S3 buckets, as well as latency for those api calls. This is a dependency of ROSA Classic and HCP clusters.

There are 2 primary efforts as part of this epic.

1. solve resiliency with: customer owned keys for OIDC (in KMS) enabling the keys to follow the cluster region
2. solve for oidc latency with Cloudfront

We will need a documented way for regenerating oidc config based on key in KMS (ROSA or OCM)

• in case someone deletes/breaks the oidc provider or Red Hat S3 fails.
• we want to be able to regenerate the key to rebuild OIDC at will.

Stretch goal: BYO oidc configuration as an option for ROSA clusters

Acceptance Criteria

• abstract regionality from our OIDC provider deployments
• use Cloudfront and CNAMEs for managed OIDC provider URLs, in order to reduce the risk of a Red Hat system from affecting customer clusters. This is instead of relying on static DNS naming.
• ensure documentation is consistent with any examples related to OIDC provider/config

Default Done Criteria

• All existing/affected SOPs have been updated.
• New SOPs have been written.
• Internal training has been developed and delivered.
• The feature has both unit and end to end tests passing in all test
  pipelines and through upgrades.
• If the feature requires QE involvement, QE has signed off.
• The feature exposes metrics necessary to manage it (VALET/RED).
• The feature has had a security review.* Contract impact assessment.
• Service Definition is updated if needed.* Documentation is complete.
• Product Manager signed off on staging/beta implementation.

Dates

Integration Testing:
Beta:
GA:

Current Status

GREEN | YELLOW | RED
GREEN = On track, minimal risk to target date.
YELLOW = Moderate risk to target date.
RED = High risk to target date, or blocked and need to highlight potential
risk to stakeholders.

References

Links to Gdocs, github, and any other relevant information about this epic.