feat(mysql/user): support non-default authentication plugins for IAM auth

[ronlevy1211]

Description of your changes

Adds an optional AuthenticationPlugin field on the MySQL User resource. When set, the user is created with CREATE USER ... IDENTIFIED WITH <plugin> [AS '<authString>'] instead of IDENTIFIED BY <password>. No password is generated, the connection secret omits the password key, and ALTER USER ... IDENTIFIED BY is skipped on Update so the provider does not downgrade plugin-auth users to native password auth.

Primary motivation is AWS RDS IAM authentication, where the DB user has no static password and clients fetch a short-lived auth token from AWS at connect time:

spec:
  forProvider:
    authenticationPlugin:
      name: AWSAuthenticationPlugin
      authString: RDS

The same field also works for other auth plugins (auth_socket, caching_sha2_password, etc.).

Backward compatibility

When AuthenticationPlugin is unset, the existing password-based flow is preserved. Existing users / manifests are unaffected.

Notable changes

• New AuthenticationPlugin{Name, AuthString} struct on UserParameters (cluster + namespaced variants)
• Create: branches to IDENTIFIED WITH when the plugin is set; password generation skipped
• Observe: skips password drift check when the plugin is set (no password to drift)
• UpdatePassword: no-op when the plugin is set (avoids downgrading the user back to password auth)
• Plugin name is quoted as a SQL identifier; auth string is quoted as a SQL value
• Examples under examples/cluster/mysql/user_iam_auth.yaml and examples/namespaced/mysql/user_iam_auth.yaml
• Regenerated CRDs and deepcopy

Fixes #106

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

• Unit tests added for both cluster and namespaced reconcilers covering: create with plugin + authString, create with plugin only (no AS clause), update no-op for plugin-auth users
• End-to-end validated against a real AWS Aurora MySQL — full results in a comment below

[ronlevy1211]

E2E test results

Validated end-to-end against an AWS Aurora MySQL (Aurora 3 / MySQL 8.0 compatible) on a non-prod cluster. Built the provider from this branch as a custom OCI image and deployed it on Crossplane pointing at the cluster.

Setup

apiVersion: mysql.sql.crossplane.io/v1alpha1
kind: User
metadata:
  name: iam-auth-test
  annotations:
    crossplane.io/external-name: iam-auth-test
spec:
  forProvider:
    authenticationPlugin:
      name: AWSAuthenticationPlugin
      authString: RDS
  providerConfigRef:
    name: mysql-shell-services
  writeConnectionSecretToRef:
    name: iam-auth-test-conn
    namespace: default

Plus a Database and Grant referring to the same user.

Results

Test	Result
User CR transitions to Ready=True, Synced=True	✅
mysql.user row shows plugin=AWSAuthenticationPlugin (proves the SQL we emit is accepted by AWS RDS)	✅
Connection secret has no password key	✅
Grant and Database reconcile successfully alongside the IAM-auth user	✅
No drift over 3 consecutive reconcile cycles (90s) — metadata.resourceVersion unchanged, no ALTER USER in provider logs (validates the Observe and UpdatePassword skip-when-plugin paths)	✅
Deleting the User CR runs DROP USER — SELECT … FROM mysql.user WHERE user = 'iam-auth-test' returns no rows	✅

Direct DB query proving the plugin was applied:

mysql> SELECT user, host, plugin FROM mysql.user WHERE user = 'iam-auth-test';
+---------------+------+--------------------------+
| user          | host | plugin                   |
+---------------+------+--------------------------+
| iam-auth-test | %    | AWSAuthenticationPlugin  |
+---------------+------+--------------------------+

[ronlevy1211]

Hi @fernandezcuesta @chlunde @JevgeniF — friendly ping for a first pass when you have a moment. The PR adds AuthenticationPlugin to the MySQL User resource so the user can be created with non-default plugins (specifically the AWS RDS AWSAuthenticationPlugin/RDS for IAM auth). E2E results against Aurora MySQL 8.0 are documented in the comment above.

[fernandezcuesta]

Can those be explicitly set mutually exclusive?
I mean either kubebuilder annotation or lateinitializer ignoredFields.
If you're able to restrict that from the API/CRD, the logic can be simplified a bit

[ronlevy1211]

Done — pushed af1d37f. Added a +kubebuilder:validation:XValidation rule on UserParameters that rejects setting both passwordSecretRef and authenticationPlugin (matches the pattern used by MSSQL User). The runtime branches in Observe/Create/UpdatePassword stay because they encode the semantic that plugin-auth users have no password, not a defensive guard. Doc comments on both fields tightened to drop the "ignored when..." wording.

[ronlevy1211]

Hey @fernandezcuesta — no rush, just a gentle nudge in case this slipped past. Pushed af1d37f last Monday with the +kubebuilder:validation:XValidation rule per your suggestion — cleaned up the implementation nicely. CI is green and the change is small. Whenever you have a few minutes for a re-look, much appreciated 🙏

Also pinging @chlunde @JevgeniF for any second opinion if Fernando is heads-down elsewhere.

[chlunde]

Could you get plugin here for drift detection and add support for changing method in Update? crossplane managed resources should be able to update any field as long as the upstream system supports it, so we don't silently ignore some types of changes

[ronlevy1211]

Done - pushed 12cd322. Three pieces:

1. Observe now SELECTs plugin, authentication_string alongside the resource-options columns. Hydrates observed.AuthenticationPlugin only when the observed plugin is non-default-password (caching_sha2_password / mysql_native_password / sha256_password are treated as "user has a password" and left as nil - they're the implicit default and would otherwise force drift on every reconcile of a password user).

2. upToDate compares AuthenticationPlugin (name + authString, nil-aware) ahead of the resource-options checks so plugin drift is caught even when ResourceOptions is nil.

3. Update detects plugin drift via Status.AtProvider.AuthenticationPlugin (cached by Observe) and handles three transitions:

   • password → plugin: emits ALTER USER ... IDENTIFIED WITH <plugin> [AS '<authString>'] (new executeAlterUserWithPluginQuery helper, mirrors the Create-time quoting - identifier-quote plugin name, value-quote authString).
   • plugin → password: falls through to the existing UpdatePassword path. ALTER USER ... IDENTIFIED BY '<pw>' both sets the password and restores the default password plugin in one statement.
   • same plugin, different authString: same ALTER USER ... IDENTIFIED WITH query with the new auth string.

The API-level XValidation rule already enforces mutual exclusivity of passwordSecretRef and authenticationPlugin, so the spec always represents one mode and the transition is unambiguous.

Tests cover the three transitions above plus an updated AuthenticationPluginSkipsAlterPassword that now sets observed == desired and asserts neither IDENTIFIED BY nor IDENTIFIED WITH runs.

[chlunde]

Could you add drift detection, or did you already discuss this?