Description

Overview

We are attempting to migrate existing Redpanda users to be managed by the Redpanda Operator (via a GitOps workflow using Argo CD) without downtime.

However, the current operator behavior prevents this use case.

Observed Behavior

When applying a User CR for an already existing user in the Redpanda cluster:

• The operator detects that the user already exists
• It automatically sets:

managedUser: false

• As a result:
  • The operator does not take full control of the user
  • Critical operations such as password rotation are not reconciled
  • Only partial management (e.g., ACLs) continues

Expected Behavior

We should be able to import existing users into operator management without requiring deletion or downtime.

Specifically:

• The operator should allow users to be marked as managed even if they already exist
• managedUser should be user-controlled (declarative) rather than automatically overridden
• This would enable:
  • Seamless migration to GitOps
  • Password rotation via Kubernetes secrets
  • Full lifecycle management by the operator

Why This is a Problem

Current behavior makes it impossible to:

• Migrate existing users without downtime
• Adopt GitOps for already provisioned environments
• Ensure consistency between desired and actual state

This is especially critical for production systems where deleting/recreating users is not feasible.

Suggested Solution

• Move managedUser control into the spec (user-defined), instead of being overridden by the operator
• Allow an explicit "import" or "adopt" behavior:
  • If managedUser: true is defined → operator should take ownership regardless of prior existence
• Alternatively, introduce:
  • An annotation or flag such as importExisting: true

Steps to Reproduce

1. Create a user directly in Redpanda (outside operator)
2. Apply a corresponding User CR via Kubernetes/Argo CD
3. Observe:
   • managedUser is set to false
4. Attempt to rotate password via secret update
5. Observe that changes are not reconciled

Impact

• Blocks migration to operator-managed users
• Prevents GitOps adoption for existing clusters
• Forces downtime or manual workarounds