[Fleet] Add instructions and generation of a service token for Fleet Server onboarding#97585
Conversation
|
Pinging @elastic/fleet (Team:Fleet) |
| <EuiFlyoutBody | ||
| banner={ | ||
| fleetServerHosts.length === 0 ? ( | ||
| fleetServerHosts.length === 0 && mode === 'managed' ? ( |
There was a problem hiding this comment.
I also updated the Add agent flyout so that the Run standalone tab can be viewed without Fleet Server being setup. I thought this was appropriate since, well, those are standalone agents! @nchaulet maybe you can help me double check if this makes sense.
| } | ||
| switch (platform) { | ||
| case 'linux-mac': | ||
| return `./elastic-agent install -f --fleet-server-service-token=${serviceToken} --fleet-server-es=${esHost}`; |
There was a problem hiding this comment.
I think with fleet-server always sudo is required as a part will be exposed.
|
Did a quick run locally and works as expected 🎉 |
| } | ||
| }; | ||
|
|
||
| export const regenerateServiceTokenHandler: RequestHandler = async (context, request, response) => { |
There was a problem hiding this comment.
Is regenerate really what we want? It means if this API endpoint is called, all existing fleet-servers will stop working. Instead I more thinking of it as "add token".
There was a problem hiding this comment.
Yes I think we probably want to generate a new token here each time
There was a problem hiding this comment.
My concern with adding a new token every time is that maybe some of them will get generated and then never used. Is that okay?
Also, since this is a new set of ES APIs, I couldn't find documentation for "retrieve all token names for this service account", which would let me generate incremental token names. Should we just generate the token names based on timestamp? token-{timestamp}?
There was a problem hiding this comment.
There will be token that are generated and never used, that is why we will need some management. But it is also the reason I want to the user to "click" a button to generate it to not have too many just because a user reloaded.
++ on timestamp for now. More APIs are still under development and we can get better here.
| import type { CheckPermissionsResponse, RegenerateServiceTokenResponse } from '../../../common'; | ||
| import { defaultIngestErrorHandler, RegenerateServiceTokenError } from '../../errors'; | ||
|
|
||
| const DEFAULT_FLEET_SERVER_SERVICE_TOKEN_NAME = 'default-fleet-server-token'; |
There was a problem hiding this comment.
The service account is already called fleet-server and it is tokens for it, so not sure we need to include it all in the name. Thinking of a future where there are multiple tokens, how will the user differentiate between these. Should we call it token-{number} for token-{timestamp} for now and later let the user specify a name if they want?
|
|
||
| const getServiceToken = useCallback(async () => { | ||
| setIsLoadingServiceToken(true); | ||
| const { data } = await sendRegenerateServiceToken(); |
There was a problem hiding this comment.
should we add some error handling around that? and use a toast notification if there is an error?
|
@elasticmachine merge upstream |
| } | ||
| switch (platform) { | ||
| case 'linux-mac': | ||
| return `sudo ./elastic-agent install -f --fleet-server-service-token=${serviceToken} --fleet-server-es=${esHost}`; |
There was a problem hiding this comment.
Can we flip this and place the --fleet-server-es first?
| case 'linux-mac': | ||
| return `sudo ./elastic-agent install -f --fleet-server-service-token=${serviceToken} --fleet-server-es=${esHost}`; | ||
| case 'windows': | ||
| return `.\\elastic-agent.exe install --fleet-server-service-token=${serviceToken} --fleet-server-es=${esHost}`; |
There was a problem hiding this comment.
On windows you will want to run that either in a cmd.exe or a Powershell that is started with Run as Administrator.
There was a problem hiding this comment.
In the copy above the commands we tell user administrator privileges are needed
| case 'deb-rpm': | ||
| return `sudo elastic-agent install -f --fleet-server-service-token=${serviceToken} --fleet-server-es=${esHost} | ||
| sudo systemctl enable elastic-agent | ||
| sudo systemctl start elastic-agent`; |
There was a problem hiding this comment.
None of this is correct on the DEB/RPM. You only need a single command, that command will automatically handle the restart of the Elastic Agent. You also need to use the enroll command on DEB/RPM.
So just change it to one-line:
elastic-agent enroll -f --fleet-server-es=${esHost} --fleet-server-service-token=${serviceToken}
There was a problem hiding this comment.
is sudo needed in this case? yes it is
|
we had previously not exposed the rpm/deb commands as we were slightly downplaying them (relying on docs support) since their usage inherently prevents being able to 'upgrade' the agent later on. We could pull them out of this as well, but it is fine to list it, and folks may use and desire it even though it isn't our recommended usage on linux to deploy. @jen-huang |
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsAPI count
API count missing comments
History
To update your PR or re-run it, just comment with: cc @jen-huang |
…Server onboarding (elastic#97585) * Don't block standalone agent instructions when not using Fleet server yet * Add service token instructions - UI only * Add route for regenerating fleet server service token * generate tokens instead of regenerate and add error catching and tests * fix i18n typo * i18n fix, add sudo, copy edits * Fix commands * Add missing test file Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…Server onboarding (#97585) (#97696) * Don't block standalone agent instructions when not using Fleet server yet * Add service token instructions - UI only * Add route for regenerating fleet server service token * generate tokens instead of regenerate and add error catching and tests * fix i18n typo * i18n fix, add sudo, copy edits * Fix commands * Add missing test file Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Jen Huang <its.jenetic@gmail.com> Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Summary
Relates to #96295. This PR adds a routes for generating (and regenerating, via sending delete + re-create requests to ES) a service token for Fleet Server. The name of this token is
default-fleet-server-token. Since we don't have designs yet, I also took a stab try at a fully-fledged set of instructions for on prem Fleet Server onboarding that includes the service token step. Copy edits are much appreciated.Remaining tasks:
Screenshots
What the user sees initially on empty state. They will also see this if they leave the page without finishing enrolling a Fleet server. In the latter case, Generate token will regenerate the
default-fleet-server-token:After they click Generate token, we display the token and install commands, the user can choose from
Linux / macOS,Windows, orRPM / DEBfor the platform. I took the commands from my own testing, our existing agent enrollment UI, and docs, please let me know if anything needs to be adjusted. The token and ES URL are dynamic:Linux / macOS:
Windows:
RPM / DEB: