Summary

The console-operator has overlapping responsibilities between oidcSetupController and oauthClientSecretController that create confusion and maintenance burden.

Description

Current State

The console-operator currently has two controllers managing authentication-related resources with unclear and overlapping responsibilities:

1. oauthClientSecretController (pkg/console/controllers/oauthclientsecret/oauthclientsecret.go)
   • Despite its OAuth-specific naming, handles BOTH IntegratedOAuth and OIDC authentication types
   • For IntegratedOAuth/None: Generates random client secret
   • For OIDC: Fetches client secret from openshift-config namespace and syncs to openshift-console/console-oauth-config
   • Sets conditions: OAuthClientSecretSyncProgressing, OAuthClientSecretSyncDegraded

1. oidcSetupController (pkg/console/controllers/oidcsetup/oidcsetup.go)
   • Handles OIDC-specific setup
   • Validates OIDC client secret exists in openshift-config namespace (line 206)
   • Syncs CA configmap from openshift-config to openshift-console
   • Updates Authentication CR status with OIDC client information
   • Sets conditions: OIDCClientConfigProgressing, OIDCClientConfigDegraded, AuthStatusHandlerProgressing, AuthStatusHandlerDegraded

Problems

1. Overlapping Resource Management
   • Both controllers fetch and validate the same OIDC client secret from openshift-config namespace
   • oidcSetupController validates the secret exists but doesn't use it
   • oauthClientSecretController fetches it again and actually syncs it to the target namespace
   • This creates duplicate work and potential for inconsistent error handling

1. Naming Confusion
   • Controller named oauthClientSecretController suggests it only handles OAuth
   • Actual behavior: handles both IntegratedOAuth AND OIDC authentication types
   • Makes code harder to understand and maintain

1. Unclear Separation of Concerns
   • Why does oidcSetupController validate secret existence but not use it?
   • Why does oauthClientSecretController handle OIDC when its name implies OAuth-only?
   • Which controller "owns" OIDC secret management?

1. Resource Duplication
   • Multiple controllers can fail independently for the same underlying issue

Proposed Solutions

Option A: Merge into Single Authentication Controller

Create a unified authenticationController that handles all authentication types with clear switch/case logic:

// authenticationController handles console authentication configuration
// for all authentication types: IntegratedOAuth, OIDC, None
type authenticationController struct {
    // ... fields
}

func (c *authenticationController) sync(ctx context.Context) error {
    authConfig := // get Authentication CR

    switch authConfig.Spec.Type {
    case AuthenticationTypeIntegratedOAuth, AuthenticationTypeNone:
        return c.syncIntegratedOAuth(ctx, authConfig)
    case AuthenticationTypeOIDC:
        return c.syncOIDC(ctx, authConfig)
    default:
        // handle unknown types
    }
}

Pros:

• Single source of truth for all authentication modes
• All secret management in one place
• Clearer code flow

Cons:

• Larger controller file
• May need careful informer setup to watch multiple namespaces

Option B: Split by Authentication Type

Refactor into two clearly-named controllers:

1. integratedOAuthController: Handles IntegratedOAuth/None authentication
   • Generates random client secrets
   • Manages openshift-console/console-oauth-config secret
   • Only runs when auth type is IntegratedOAuth or None

1. oidcController: Handles OIDC authentication (rename/merge from current oidcSetupController)
   • Fetches client secret from openshift-config
   • Syncs client secret to openshift-console/console-oauth-config
   • Syncs CA configmaps
   • Updates Authentication CR status
   • Only runs when auth type is OIDC

Pros:

• Clear naming matches responsibility
• Easier to understand which controller handles what
• Can optimize informer watching per controller
• Follows single responsibility principle

Cons:

• Need to coordinate secret ownership between controllers
• May need additional cleanup logic when switching between auth types

Acceptance Criteria

• Single source of truth for each authentication type's secret management
• Controller names clearly indicate their responsibility (no "oauth" controller handling OIDC)
• No duplicate resource fetching between controllers
• All existing functionality preserved (no behavior changes)
• Unit tests updated to reflect new structure
• Integration tests pass (especially OIDC rollback scenarios)
• Code comments clearly document each controller's responsibility
• Error conditions remain consistent or improved (no degradation in error reporting)

Additional Context

This refactoring will make the codebase more maintainable and reduce the risk of bugs like OCPBUGS-61432 , where overlapping responsibilities between controllers made it harder to identify the root cause.

Current code locations:

• pkg/console/controllers/oauthclientsecret/oauthclientsecret.go
• pkg/console/controllers/oidcsetup/oidcsetup.go
• pkg/console/starter/starter.go (controller initialization)