Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a tool for creating enrollment tokens #74890

Merged
merged 15 commits into from
Jul 15, 2021

Conversation

jkakavas
Copy link
Member

@jkakavas jkakavas commented Jul 5, 2021

This change introduces a CLI tool that can be used to create
enrollment tokens. It doesn't require credentials, but simply
write access to the local filesystem of a node. It uses an
auto-generated user in the file-realm with superuser role.

For this purpose, this change also introduces a base class for a
CLI tool that can be used by any CLI tool needs to perform actions
against an ES node as a superuser without requiring credentials
from the user. It is worth noting that this doesn't change our
existing thread model, because already an actor with write access
to the filesystem of an ES node, can become superuser (again, by
adding a superuser to the file realm, albeit manually).

jkakavas added 2 commits July 5, 2021 09:26
This change introduces a CLI tool that can be used to create
enrollment tokens. It doesn't require credentials, but simply
write access to the local filesystem of a node. It uses an
auto-generated user in the file-realm with superuser role.

For this purpose, this change also introduces a base class for a
CLI tool that can be used by any CLI tool needs to perform actions
against an ES node as a superuser without requiring credentials
from the user. It is worth noting that this doesn't change our
existing thread model, because already an actor with write access
to the fs of an ES node, can become superuser (again, by
adding a superuser to the file realm, albeit manually).
@jkakavas jkakavas added :Security/Security Security issues without another label v8.0.0 labels Jul 5, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Jul 5, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drive by ...

jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Jul 8, 2021
@jkakavas jkakavas requested review from tvernum and bytebilly July 8, 2021 21:05
@tvernum
Copy link
Contributor

tvernum commented Jul 9, 2021

Thanks for requesting a review, but my original comments were just a drive-by, I don't think I need to do a full review unless you specifically want it.

Feel free to merge when you have the OK from the project team.

@jkakavas
Copy link
Member Author

jkakavas commented Jul 9, 2021

Thanks for requesting a review, but my original comments were just a drive-by, I don't think I need to do a full review unless you specifically want it.

I just triggered the button on the top right mostly so that you get the PR in the GH list of PRs for convenience. Thanks for the drive-by comments !

@jkakavas jkakavas requested review from BigPandaToo and removed request for bytebilly July 12, 2021 09:26
@jkakavas jkakavas requested a review from lockewritesdocs July 12, 2021 14:51
@jkakavas
Copy link
Member Author

part-1-fips failed because of #75221, unrelated flaky test

@jkakavas
Copy link
Member Author

@elasticsearchmachine run elasticsearch-ci/part-1-fips

Copy link
Contributor

@BigPandaToo BigPandaToo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lockewritesdocs
Copy link
Contributor

@elasticmachine run elasticsearch-ci/docs

Copy link
Contributor

@lockewritesdocs lockewritesdocs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few non-blocking suggested changes. LGTM otherwise 🥳

docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
docs/reference/commands/create-enrollment-token.asciidoc Outdated Show resolved Hide resolved
settings = env.settings();
}

ensureFileRealmEnabled(settings);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because file realms don't have Secure Settings, I would move this before the password prompt, and maybe make it the base implementation of validate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We chatted and we're moving ensureFileRealmEnabled(settings); higher up but not adding it to a default implementation of validate()

attributesChecker.check(terminal);
final boolean forceExecution = options.has(force);
checkClusterHealthWithRetries(newEnv, terminal, 5, forceExecution);
executeCommand(terminal, options, newEnv);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I would pass the username and password to this method instead of making them class members. It's more clear the lifecycle like this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'd need to pass them as parameters to all checkClusterHealthWithRetries, executeCommand, cleanup. I like the fact that we keep ownership of the password here and close it in all cases etc. Happy to change, but I miss the point of "It's more clear the lifecycle like this." , I'll ping you to chat

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we chatted and I made the change as suggested

Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
I only had two very minor comments.

@jkakavas jkakavas merged commit cb37989 into elastic:master Jul 15, 2021
masseyke pushed a commit to masseyke/elasticsearch that referenced this pull request Jul 16, 2021
This change introduces a CLI tool that can be used to create
enrollment tokens. It doesn't require credentials, but simply
write access to the local filesystem of a node. It uses an
auto-generated user in the file-realm with superuser role.

For this purpose, this change also introduces a base class for a
CLI tool that can be used by any CLI tool needs to perform actions
against an ES node as a superuser without requiring credentials
from the user. It is worth noting that this doesn't change our
existing thread model, because already an actor with write access
to the fs of an ES node, can become superuser (again, by
adding a superuser to the file realm, albeit manually).

Co-authored-by: Adam Locke <[email protected]>
ywangd pushed a commit to ywangd/elasticsearch that referenced this pull request Jul 30, 2021
This change introduces a CLI tool that can be used to create
enrollment tokens. It doesn't require credentials, but simply
write access to the local filesystem of a node. It uses an
auto-generated user in the file-realm with superuser role.

For this purpose, this change also introduces a base class for a
CLI tool that can be used by any CLI tool needs to perform actions
against an ES node as a superuser without requiring credentials
from the user. It is worth noting that this doesn't change our
existing thread model, because already an actor with write access
to the fs of an ES node, can become superuser (again, by
adding a superuser to the file realm, albeit manually).

Co-authored-by: Adam Locke <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Security Security issues without another label Team:Security Meta label for security team v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants