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

Simplify the environment variables needed for credential bootstrapping #633

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

adutra
Copy link
Contributor

@adutra adutra commented Jan 9, 2025

I know there has been some back and forth on this topic, so apologies to bring it up again.

I would like to propose a simplification of the environment variables needed to bootstrap credentials, for a few reasons:

  1. It currently requires too many variables;
  2. Encoding the realm and the principal name in the variable names is error prone.
  3. It currently does not take system properties also into account;

Instead I'm proposing to use just one system property or environment variable that contains all the data we need.

```bash
env POLARIS_BOOTSTRAP_DEFAULT-REALM_ROOT_CLIENT_ID=my-client-id POLARIS_BOOTSTRAP_DEFAULT-REALM_ROOT_CLIENT_SECRET=my-client-secret <bootstrap command>
```
export POLARIS_BOOTSTRAP_CREDENTIALS=my_realm,root,my-client-id,my-client-secret;my_realm2,root,my-client-id2,my-client-secret2
Copy link
Contributor

Choose a reason for hiding this comment

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

This syntax feels a bit obtuse... I would almost prefer a JSON blob or something

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about that too but shoveling json in an environment variable inside a shell script is calling for trouble with double-quotes and escape chars. So I thought this plain text format was more appropriate. Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense. In that case maybe the existing syntax is okay, and for a more "ergonomic" syntax we can consider arguments to the bootstrap command itself? Perhaps a JSON payload there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's exactly my plan in #605 – for now, it needs the environment variable, but I will introduce proper arguments to the bootstrap command.

Copy link
Contributor

Choose a reason for hiding this comment

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

from my POV the complexity of the value is justified by not having to deal with - in the env. var. names (which is part of the default-realm name)

Copy link
Contributor

@dimas-b dimas-b left a comment

Choose a reason for hiding this comment

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

LGTM overall 👍

I agree that eventually we should have the bootstrap command support user-provided secrets, but if it helps dealing with bootstrapping servers in the short term, I think a bit of complication in the env. names / values is tolerable.

@Test
void nullString() {
PolarisCredentialsBootstrap credentials = PolarisCredentialsBootstrap.fromString(null);
assertThat(credentials.credentials).isEmpty();
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: why not make a package-private "parse" method visible to tests, but keep the field private? I think it'd provide better encapsulation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants