-
Notifications
You must be signed in to change notification settings - Fork 356
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
feat: det deploy local generates a password for you [DET-10197] #9518
feat: det deploy local generates a password for you [DET-10197] #9518
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9518 +/- ##
==========================================
- Coverage 49.83% 49.82% -0.02%
==========================================
Files 1246 1246
Lines 162111 162159 +48
Branches 2887 2887
==========================================
+ Hits 80791 80792 +1
- Misses 81149 81196 +47
Partials 171 171
Flags with carried forward coverage won't be shown. Click here to find out more.
|
✅ Deploy Preview for determined-ui canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for working on this. one comment:
@@ -172,6 +176,10 @@ def master_up( | |||
if initial_user_password is not None: | |||
master_conf["security"]["initial_user_password"] = initial_user_password | |||
make_temp_conf = True | |||
elif master_conf["security"].get("initial_user_password") is None: | |||
generated_user_password = secrets.token_urlsafe(16) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what chars does this include? can we make sure it's can be picked up with a double click? eg -
would break that flow. also maybe we printout what they'd use to create a user
``
det -u admin u create USERNAME --password $GENRATEDPWD`
to make it easier
actually, why not prompt the user for a pwd if it's an interactive shell session? they can confirm to keep/get the autogenerated version or provide a new one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good point -- I'll try extending this flow a little bit. I think it should still print the autogenerated password in case this is run with a closed stdin (i.e. non-interactively) or the user hits Ctrl+C or something, but prompting to change the password immediately would likely be helpful in the majority of cases. Thanks!
I'll also aim to make this something that can't generate hyphens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would be great to include as additional cases to your e2e test!
- CLI: If no user accounts have already been created, and neither | ||
``security.initial_user_password`` in master.yaml nor ``--initial-user-password`` is present when | ||
running ``det deploy local`` with the ``master-up`` or ``cluster-up`` commands, an initial | ||
password will be generated and displayed to the user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if this is what is intended:
:orphan:
Security Fixes
- CLI: If no user accounts have already been created, and neither
security.initial_user_password
in master.yaml nor the--initial-user-password
is specified when
runningdet deploy local
with themaster-up
orcluster-up
commands, an initial
password will be generated and displayed to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind clarifying what the proposed change is? Just the addition of the word "the" or was there something else I missed? I would probably say "the --initial-user-password
CLI flag" in that case, to be extra clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggested edits
@hamidzr I added a prompt, with the generated password still being printed as a fallback if the user can't answer the prompt correctly. Ready for re-review, I think. |
df866ff
to
dda0b7b
Compare
except ValueError: | ||
random_password_characters = string.ascii_uppercase + string.ascii_lowercase + string.digits | ||
generated_user_password = "".join( | ||
[secrets.choice(random_password_characters) for _ in range(16)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't guaranteed to select a password which meets the security requirements. It could generate sixteen lowercase letters, for example.
The way I've done this in the past is to select one from each set, fill the rest of the length from the combined character set, then shuffle the list by swapping each element with a random value from 0-len before joining.
That may not matter for local deployments, but I figured it was worth mentioning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point -- I'll switch it to that. Thanks.
- CLI: If no user accounts have already been created, and neither | ||
``security.initial_user_password`` in master.yaml nor the ``--initial-user-password`` CLI flag is | ||
present when running ``det deploy local`` with the ``master-up`` or ``cluster-up`` commands, an | ||
initial password will be generated and displayed to the user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jesse-amano-hpe does the system display the option to change the auto generated password? Also, we should probably clarify this is "when deploying locally" (my fault)....
e.g.,
:orphan:
Security Fixes
- CLI: When deploying locally using
det deploy local
withmaster-up
orcluster-up
commands and no user accounts have been created yet, an initial password will be automatically generated and shown to the user (with the option to change it) if neithersecurity.initial_user_password
inmaster.yaml
nor the--initial-user-password
CLI flag is
present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally looks good, but I want to defer approval to @hamidzr since he initially reviewed the PR
Resource.MASTER, | ||
master_name, | ||
{"initial-user-password": conf.USER_PASSWORD}, | ||
["delete-db"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does "delete-db" command have to do with this feature? is this a stray change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because an existing database could come with existing user/password settings (including those generated by other tests and not known to this test), which would break the tests. This gets us a clean slate.
e2e_tests/tests/deploy/test_local.py
Outdated
def test_master_up_interactive_password() -> None: | ||
cluster_name = "test_master_up_interactive_password" | ||
master_name = f"{cluster_name}_determined-master_1" | ||
password_input = "XDdOB9VUp8FLpTZ2" | ||
|
||
with resource_manager( | ||
Resource.MASTER, | ||
master_name, | ||
boolean_flags=["delete-db"], | ||
cmd_input=bytes(f"{password_input}\n{password_input}\n", "utf8"), | ||
) as master_up_command: | ||
client = docker.from_env() | ||
|
||
containers = client.containers.list(filters={"name": master_name}) | ||
assert len(containers) > 0 | ||
assert ( | ||
b"Determined Master was launched without a strong initial_user_password set." | ||
in master_up_command.stdout | ||
) | ||
|
||
containers = client.containers.list(filters={"name": master_name}) | ||
assert len(containers) == 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we run this with multiple cases? of passwords that pass & those that don't & and empty case?
Hamid is out for the next couple weeks, so, scratch that. I'll approve once my other comments are resolved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
… not specified" This reverts commit 203370a.
…ce hyphens etc can be disruptive
…launched from subprocess
ed8ebfa
to
5fb7cc3
Compare
Ticket
DET-10197
Description
BREAKING CHANGE: if an initial user password is not specified, the
det deploy local
command generates one automatically; if that random password is recognized as the correct one fordetermined
, it is printed so users can log in with it and change their password. Otherwise, it is assumed that this is a relaunch of a cluster with an existing database.The proposal for this change was first described here: https://hpe-aiatscale.slack.com/archives/CLCE8D998/p1716571996243779?thread_ts=1716404697.160779&cid=CLCE8D998
Additional notes
det deploy aws
anddet deploy gcp
can rely on Terraform state to determine whether a database (or database image) already contains passwords, and prompt interactively if not, andhelm
can run some simple checks during templating. However,det deploy local
sets up a database in a docker container based on a volume that may or may not be empty, and it's hard to know migration states etc. until master is healthy. Rather than rely onmaster
to decide in this case (which has caused problems in the past), this solution guarantees there will always be a password set on cluster creation, with the only major downside being that the admin user is still responsible for changing their password if the deployment logs are somehow exposed long-term.Test Plan
I've manually tested and added integration tests, but it is probably worth triple-checking that the following is still true on next release:
det deploy local master-up --delete-db
prompts for the user to enter an initial password, displays requirements if the first attempt is blank or weak, and falls back to displaying a generated password if the user can't set this correctly.det deploy local master-up
(with an existing database volume) allows login with whatever passwords were set before and does not print the generated password messagedet deploy local master-up --delete-db --initial-user-password=$PASSWORD
sets up the provided passwords and does not print the generated password messagetime det deploy local master-up --det-version='203370a6cdb048aaa579c7406f584bb428e76df4' --master-port=8080 --delete-db --initial-user-password '' &
(runs detached in background) skips prompting for a password due to the detached TTY, and displays the generated password (might need tofg
the job to see it) in under 2 minutes (should not wait ~10 minutes for an overall task timeout)Checklist
docs/release-notes/
.See Release Note for details.