Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[SM-1129] Run command with secrets #621
[SM-1129] Run command with secrets #621
Changes from 35 commits
07e1fe9
391d6b1
bd75024
48f3841
1e5d63a
a52b989
710ae61
f3ad7f3
c7d29ad
211d067
26af620
0f4d996
7516a45
a19e820
bafdaad
5fc71d3
6ad88b8
accc97e
b78284b
c2ee84c
acbffe6
9eb8e9f
4dfde95
9fc608b
1ab92be
ce96046
8e51cf9
68306b3
2e673b6
b6e676a
65b5492
f483b30
64c30c6
0e87279
606185c
30da24c
8cdf289
cd56439
14fa8df
cb9903a
9511ba2
55c9e72
0c6128a
09bdee7
9ae6078
4a4a8d8
cb6f987
eb29e7d
2da9ca9
deebd5d
2c5a279
a836b65
17a4d28
14a9e50
c93bf8f
5be08ed
e06e48f
3df1c6d
68973d0
83eb725
61b41fc
9f6a165
3080dac
23ab8f4
3fcd32c
c7aad3f
eda00aa
9839b94
7362764
f9629b8
15b1114
4d4922f
1c6ffbc
75e3d8b
e86aa2e
b86d026
f4c2598
f9456b8
e31c689
4a5aeb3
5bdf99c
f9c9946
a75f53e
4770dbf
87fc76d
bc1a6ff
a0f78a3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Check warning on line 95 in crates/bws/src/cli.rs
Codecov / codecov/patch
crates/bws/src/cli.rs#L95
Check warning on line 102 in crates/bws/src/cli.rs
Codecov / codecov/patch
crates/bws/src/cli.rs#L102
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.
I don't think we use this. Should we ?
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.
Good catch. I think I missed this when refectoring the command at some point. Removed in f9c9946.
Check warning on line 247 in crates/bws/src/cli.rs
Codecov / codecov/patch
crates/bws/src/cli.rs#L247
Check warning on line 416 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L413-L416
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.
The
process_command
function is getting quite big already, do you mind splitting this to a separate function?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.
Yeah. I can probably move this stuff out of here in a similar fashion to how it's being handled in #809.
Check warning on line 420 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L418-L420
Check warning on line 426 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L423-L426
Check warning on line 436 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L428-L436
Check warning on line 438 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L438
Check warning on line 445 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L441-L445
Check warning on line 451 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L447-L451
Check warning on line 456 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L453-L456
Check warning on line 463 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L459-L463
Check warning on line 469 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L466-L469
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.
will shell start with invalid environment variables ? don't we need to filter those out ?
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.
Great questions!
In the first case, I'd use an "end of arguments" (
--
) operator to construct a command like that to ensure that the shell is passing all of the arguments to our command:bws run -- docker run --platform "linux/amd64" --rm --name "ubuntu-1" ubuntu echo 'hello'
.In the case of the multi-line
if
statement, I'm not sure if there's a way forbws
to handle that, as the first new-line passed to the shell would immediately attempt to executebws run if [ "$ENV1" = "1234" ]; then
on its own. I'm unsure if anything other than a shell builtin could trigger the interactive multiline input.I wouldn't generally use the
run
command to execute more intircate ad-hoc shell commands like that (I'd put something like that in a script), but if you wanted to, you could wrap it in single-quotes to avoid having the shell executing or interpolating anything before it's passed to our command. Something like the following would work:I would prefer keeping the default behavior to use the key names, as it greatly improves usability and is in-line with CLIs that have similar functionality. Making UUIDs the default would require more effort for users to use the
run
command to replace things like local env files, where the environment variables wouldn't have a Bitwarden-generated secret UUID to reference.What would you think of a
BWS_USE_UNIQUE_NAMES=1
environment variable that could be set that would ensure that all secrets that are set get the secret UUID (in snake_case) appended to them? So, if you're running a script where you have secrets with identical names, you can ensure uniqueness. We could possibly add an equivalent argument (--use-unique-names
?), but I feel like you would be much more likely to need that functionality on a per-script/session basis, rather than as a one-off. Either way, I think having something like that would help people that can't guarantee the uniqueness of their secret names.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 will set the environment variables, even if they're not POSIX-compliant, yes. You'll get warnings printed to stderr stating that you have some non-POSIX-compliant key names, but they are technically set correctly by the
run
command. I figured that if someone were to executing a binary/script that had less restrictive naming conventions for environment variables, we could leave them set. For example:would work, since
getenv
doesn't seem to require POSIX compliance. I imagine the same is possible for equivalent libs in other languages.I'm open to un-setting them, but I'm not sure how people might feel about that if they're used to not being limited by POSIX-compliance.
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.
I like this, being explicit in the cli options is better.
And like you mentioned, makes the solution more future proof, when users wants to do things by Id.
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.
I am fine either way, just want to avoid
bws run
not working because of some special characters in the secret key.Check warning on line 477 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L471-L477
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.
for additional security, do we want to remove "BWS_ACCESS_TOKEN" from inherited env variables ?
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.
I have also wondered this. I added the
--no-inherit-env
argument for a similar reason, but I suppose I could remove that variable by default as well.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.
@bwdil thoughts ?
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.
@mzieniukbw please unpack what you mean by 'for additional security' what is your concern? About having
BWS_ACCESS_TOKEN
inherited and how it gets subsequently used thereafter?What are the security gains you're trying to achieve and what's the risk?
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.
@bwdil My though is that whatever get's executed as part of
bws run
is probably something that needs to run one off and just need read access to some of the secrets.With
BWS_ACCESS_TOKEN
we expose much more than intended:bws run
can specify a project, but with access token we have access to every single of themThere 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.
@mzieniukbw if
BWS_ACCESS_TOKEN
is not required for subsequent commands that get spawned then it can be cleared from env to limit exposure. I think your concern is something thatbws run
invokes (another process) getting hijacked and then stealing the access token.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.
Sounds good. I'll remove the
BWS_ACCESS_TOKEN
var by default as well then. Thanks for calling this out.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.
BWS_ACCESS_TOKEN
is now unset by default.Check warning on line 494 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L480-L494
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.
I don't think this is needed, we're already calling child.wait() above, any other calls will just return immediately, I think
Check warning on line 505 in crates/bws/src/main.rs
Codecov / codecov/patch
crates/bws/src/main.rs#L496-L505
Check warning on line 36 in crates/bws/src/render.rs
Codecov / codecov/patch
crates/bws/src/render.rs#L36
Check warning on line 8 in crates/bws/src/util.rs
Codecov / codecov/patch
crates/bws/src/util.rs#L5-L8
Check warning on line 10 in crates/bws/src/util.rs
Codecov / codecov/patch
crates/bws/src/util.rs#L10