Repository navigation
Install the Elastic Slack app with a UIAM service account - #292776
vigneshshanmugam wants to merge 28 commits into
Conversation
Serverless installs behind xpack.actions.relay.uiam.enabled send a service-account id instead of an API key, and reuse of that id stays behind manage_security. Co-authored-by: Cursor <cursoragent@cursor.com>
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
…vigneshshanmugam/kibana into feat/relay-uiam-service-account-install
API Contract Breaking ChangesThe following breaking change(s) were detected across the public OpenAPI surface, grouped by stability tier. Stable and Technical Preview changes fail the check and should be resolved; Experimental changes are informational. Experimental — informational, not blocking merge (2)Experimental APIs are allowed to introduce breaking changes. These are listed for visibility only and do not fail this check.
What to do
See the |
…-service-account-install
…-service-account-install
…-service-account-install
…-service-account-install
PR size reminderThis PR has 1234 added lines of reviewable code, which is above the 500-line guideline for Nightshift PRs. Large PRs get significantly less review engagement and take longer to merge. Consider splitting this into smaller, focused PRs before requesting review. |
| await this.writeConnection(soClient, { | ||
| ...connection, | ||
| status: RELAY_APP_CONNECTION_STATUS.notConnected, | ||
| apiKeyId: null, | ||
| tenantKey: null, |
There was a problem hiding this comment.
Severity: low
Disconnect now retains all attributes via ...connection, including an old error. After a failed unbind is retried successfully (or an errored install is disconnected), getStatus still includes that error alongside not_connected, so users see a stale failure even though disconnect succeeded. Clear the error when writing the retained document.
getStatus returns ...(connection.error ? { error: connection.error } : {}) regardless of status.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
…-service-account-install # Conflicts: # x-pack/platform/plugins/shared/security/server/service_accounts/es_service_accounts.test.ts # x-pack/platform/plugins/shared/security/server/service_accounts/es_service_accounts.ts # x-pack/platform/plugins/shared/security/server/service_accounts/uiam_service_accounts.ts
Co-authored-by: Cursor <cursoragent@cursor.com>
|
|
||
| const RELAY_SERVICE_ACCOUNT_NAME_PREFIX = 'nightshift-relay-agent-builder'; | ||
|
|
||
| const RELAY_SERVICE_ACCOUNT_ROLES = ['viewer']; |
There was a problem hiding this comment.
The uiam service account create method now require roles, that is better than using user roles, but this open the question of what role we want to user for that service account? we probably a new built in role? I would address that as a follow up
There was a problem hiding this comment.
@vigneshshanmugam curious to have your thoughts on that, I think we should have a dedicated built in role for relay
There was a problem hiding this comment.
I agree, viewer is too broad. Can we explore creating a dedicated role for Relay's use case? This will allow you to dynamically update the required privileges over time as well, as your requirements change.
There was a problem hiding this comment.
@legrego do you have any thoughs on how we could create that role? should we just create a custom role in Kibana at runtime (it do not seems the more robust) Or should we go the way of adding a built-in role? also it seems there is not really a system role concept
…-service-account-install Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
| ...connection, | ||
| status: RELAY_APP_CONNECTION_STATUS.error, | ||
| apiKeyId: null, | ||
| serviceAccountId: null, |
There was a problem hiding this comment.
If the revoke step fails (errors are swallowed), then we will erase the service account id from Kibana's memory here. Won't we end up with an orphaned service account at that point?
There was a problem hiding this comment.
Yes we have the same behaviour for api keys, user should still be able to manually revoke the old service account, but it avoid a out of sync state with a service account id stored in a saved object that we cannot revoke anymore, the error is logged
|
|
||
| const RELAY_SERVICE_ACCOUNT_NAME_PREFIX = 'nightshift-relay-agent-builder'; | ||
|
|
||
| const RELAY_SERVICE_ACCOUNT_ROLES = ['viewer']; |
There was a problem hiding this comment.
I agree, viewer is too broad. Can we explore creating a dedicated role for Relay's use case? This will allow you to dynamically update the required privileges over time as well, as your requirements change.
…s/assumable_by.ts Co-authored-by: Larry Gregory <lgregorydev@gmail.com>
…vigneshshanmugam/kibana into feat/relay-uiam-service-account-install
| delete: async (request, id, params) => | ||
| requireServiceAccounts().management.delete(request, id, params), |
There was a problem hiding this comment.
Severity: P2 (Medium)
Reject a non-forced delete when bound workloads remain; the delegate currently resolves successfully while leaving the account active.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
| const license = await this.server.licensing.getLicense(); | ||
| const agentId = await credential.resolveAgentId(); |
There was a problem hiding this comment.
Severity: P3 (Low)
Add a regression test for license lookup failure after credential creation to verify cleanup runs and Relay is not called.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
💔 Build Failed
Failed CI StepsMetrics [docs]Unknown metric groupsworkflow yaml validation
History
|
Summary
xpack.actions.relay.uiam.enabledis on, Slack connect creates UIAM service account, adds Relay (relay-service) toassumable_byin the security plugin, and sends onlyuiam_service_account_idtoRelayClient.startInstall.kibana_api_key. That path is unchanged when the flag is off.{ name }only. Callers cannot passassumable_byortrustedPlatformAssumers.Part of elastic/relay-service#340.
Live install still depends on Relay storing that id (elastic/relay-service#325) and on Agent Builder accepting the exchanged token. UIAM still snapshots the creating user's application privileges and cannot re-bound them (#284463).
@legrego On the security side, we had to made change to allow to pass additionnal
assumable_by, and add a revoke method, let me know if it's seems acceptable and any change we could make there.@vigneshshanmugam I also refactored this a lot to avoid too much duplicate code between the API key/service account path.
Identify risks
Test plan
node scripts/jestfor the Slack app service, Relay client, UIAM and Elasticsearch service accounts, and the core service-account contractuiam_service_account_idRelease notes
release_note:skipThe behavior is behind
xpack.actions.relay.uiam.enabled, which defaults to off.Made with Cursor