Add regenerate-bot-tokens operation for JWT key rotation

[pmbrull]

Summary

• Adds a new regenerate-bot-tokens subcommand to OpenMetadataOperations that regenerates JWT tokens for all bot users
• Needed when rotating JWT signing keys or changing the cluster name (e.g., DR scenario moving from POV to PROD)
• Paginates through all non-deleted bots, regenerates JWT tokens for those using JWT auth, and displays results in an ASCII table

Test plan

• Run ./openmetadata-ops.sh regenerate-bot-tokens -c conf/openmetadata.yaml against a local environment with bots configured
• Verify tokens are regenerated for all JWT-authenticated bots
• Verify bots without JWT auth or without associated users are correctly skipped
• Verify the new tokens work by authenticating with the regenerated bot token

Closes open-metadata/openmetadata-collate#3157

[github-actions]

🟡 Playwright Results — all passed (23 flaky)

✅ 3330 passed · ❌ 0 failed · 🟡 23 flaky · ⏭️ 183 skipped

Shard	Passed	Failed	Flaky	Skipped
🟡 Shard 1	453	0	2	2
🟡 Shard 2	304	0	1	1
🟡 Shard 3	653	0	8	33
🟡 Shard 4	720	0	7	47
✅ Shard 5	591	0	0	67
🟡 Shard 6	609	0	5	33

🟡 23 flaky test(s) (passed on retry)

• Features/CustomizeDetailPage.spec.ts › Dashboard - customization should work (shard 1, 1 retry)
• Flow/Tour.spec.ts › Tour should work from welcome screen (shard 1, 1 retry)
• Features/ColumnBulkOperations.spec.ts › should navigate through pages (shard 2, 1 retry)
• Features/DataProductRenameConsolidation.spec.ts › Rename then add tags - assets should be preserved (shard 3, 1 retry)
• Features/DataQuality/ColumnLevelTests.spec.ts › Column Values Sum To Be Between (shard 3, 1 retry)
• Features/DataQuality/DataQualityPermissions.spec.ts › User with TEST_CASE.VIEW_BASIC can view test case CONTENT details in UI (shard 3, 1 retry)
• Features/DataQuality/TestCaseIncidentPermissions.spec.ts › User with only VIEW cannot PATCH incidents (shard 3, 1 retry)
• Features/DataQuality/TestCaseResultPermissions.spec.ts › User with only VIEW cannot PATCH results (shard 3, 1 retry)
• Features/EntitySummaryPanel.spec.ts › should display summary panel for table (shard 3, 1 retry)
• Features/ImpactAnalysis.spec.ts › Verify Upstream connections (shard 3, 1 retry)
• Features/Permissions/GlossaryPermissions.spec.ts › Team-based permissions work correctly (shard 3, 1 retry)
• Flow/ObservabilityAlerts.spec.ts › Test Suite alert (shard 4, 1 retry)
• Pages/Customproperties-part2.spec.ts › entityReferenceList shows item count, scrollable list, no expand toggle (shard 4, 1 retry)
• Pages/Domains.spec.ts › Verify domain and subdomain asset count accuracy (shard 4, 1 retry)
• Pages/Domains.spec.ts › Rename domain with deeply nested subdomains (3+ levels) verifies FQN propagation (shard 4, 1 retry)
• Pages/Entity.spec.ts › Tag Add, Update and Remove for child entities (shard 4, 1 retry)
• Pages/Entity.spec.ts › Glossary Term Add, Update and Remove (shard 4, 1 retry)
• Pages/Entity.spec.ts › Inactive Announcement create & delete (shard 4, 1 retry)
• Pages/Glossary.spec.ts › Glossary Term Update in Glossary Page should persist tree (shard 6, 1 retry)
• Pages/Login.spec.ts › Refresh should work (shard 6, 1 retry)
• Pages/Users.spec.ts › Permissions for table details page for Data Consumer (shard 6, 1 retry)
• Pages/Users.spec.ts › Check permissions for Data Steward (shard 6, 1 retry)
• VersionPages/EntityVersionPages.spec.ts › Directory (shard 6, 1 retry)

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace

[gitar-bot]

Code Review ✅ Approved 5 resolved / 5 findings

Adds regenerate-bot-tokens operation for JWT key rotation, addressing hardcoded expiry overrides, null pointer exceptions on pagination boundaries, URL injection via CLI params, and error handling for failed regenerations. All findings resolved.

✅ 5 resolved

✅ Bug: Hardcoded Unlimited expiry overrides bots' existing token expiry

📄 openmetadata-service/src/main/java/org/openmetadata/service/util/OpenMetadataOperations.java:2519
At line 2519, JWTTokenExpiry.Unlimited is hardcoded when regenerating tokens. This silently overrides whatever expiry a bot's token originally had (e.g., 7-day, 30-day, 90-day) with Unlimited, which is a security regression. The canonical pattern (used in UserResource.java) is to read the existing expiry from the bot's stored JWTAuthMechanism config and pass it through.

✅ Bug: NPE when getPaging() returns null on empty/last page

📄 openmetadata-service/src/main/java/org/openmetadata/service/util/OpenMetadataOperations.java:2533
At line 2533, botPage.getPaging().getAfter() is called without a null guard. The ResultList class has constructors that leave paging = null (no-arg constructor and single-arg ResultList(List<T> data)). If listAfter returns a ResultList with null paging (e.g., when there are no bots), this will throw a NullPointerException, causing the command to fail and fall into the outer catch block with a confusing error message.

✅ Security: CLI expiry param is not URL-encoded, enabling URL injection

📄 openmetadata-service/src/main/java/org/openmetadata/service/util/OpenMetadataOperations.java:2500 📄 openmetadata-service/src/main/java/org/openmetadata/service/util/OpenMetadataOperations.java:2478
The expiry CLI parameter is concatenated directly into the URL at line 2500 without URL-encoding or validation against the JWTTokenExpiry enum values. A value like Unlimited&admin=true would be passed verbatim into URI.create(...), injecting arbitrary query parameters into the request.

Additionally, the CLI declares expiry as a plain String (not the JWTTokenExpiry enum), so picocli won't reject invalid values at parse time. The user only gets a confusing 404 from the server when JAX-RS fails to bind an invalid enum value.

Fix both by (a) URL-encoding the value and (b) declaring the CLI option type as JWTTokenExpiry so picocli validates it upfront.

✅ Edge Case: Endpoint returns 200 even when all bots fail regeneration

📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/teams/UserResource.java:1023
The regenerateBotTokens endpoint always returns Response.ok() (HTTP 200) regardless of how many bots failed. If every bot fails, the caller still gets a 200 with failedBots populated but no HTTP-level indication of failure. The CLI side handles this correctly (returns exit code 1 if failedBots is non-empty), but other HTTP callers (e.g., UI, scripts) would need to inspect the response body to detect failures.

Consider returning 207 Multi-Status when there are partial failures, or 500 when all bots fail, to give HTTP-level callers a clear signal.

✅ Bug: CLI returns exit code 0 even when all bot token regenerations fail

📄 openmetadata-service/src/main/java/org/openmetadata/service/util/OpenMetadataOperations.java:2552
The old server-API-based code correctly returned exit code 1 when any bot failed (return result.getOrDefault("failedBots", List.of()).isEmpty() ? 0 : 1;). The new direct-DB code at line 2552 always returns 0, regardless of how many bots ended up in FAILED status. This makes the command unsuitable for scripted/CI use where the exit code signals success or failure.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud