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

Polykey secrets env integration #289

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

Conversation

brynblack
Copy link
Member

@brynblack brynblack commented Sep 27, 2024

Description

This PR integrates the polykey secrets env command into the development shell hook, to securely load development secrets into the development environment.

Tasks

  • 1. Replace . ./.env with pk secrets env ...
  • 2. Update CI to include Polykey and pull from seed node

Final checklist

  • Domain specific tests
  • Full tests
  • Updated inline-comment documentation
  • Lint fixed
  • Squash and rebased
  • Sanity check the final build

@brynblack brynblack self-assigned this Sep 27, 2024
@tegefaulkes
Copy link
Contributor

@brynblack does this not link back to any issues?

@@ -101,7 +101,7 @@
shellHook = ''
echo "Entering $(npm pkg get name)"
set -o allexport
. ./.env
. <(pk secrets env Polykey-CLI:.)
Copy link
Member

Choose a reason for hiding this comment

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

This should just be Polykey-CLI, no need for :..

Also again, this assumes we have a vault called Polykey-CLI, let's also make this command fail-safe, so that even if the vault doesn't exist, it can continue.

The usual way to do this is with || true when the command returns a non-zero exit code.

Also note that set -o allexport ensures that all variables declared afterwards is exported.

If the pk secrets env command produces exported variables, that isn't necessary anymore. This is why I wanted to ensure that sourcing doesn't do that by default.

The final thing is the lack of a vault schema making this very implicit, we are essentially injecting arbitrary global variables - whereas what we want is a schema defining what we expect to be in the vault. We have an issue for this too.

Also pk is an alias, the official program command should be polykey.

Another thing is that this assumes polykey exists in the development shell o r available in the CLI. I usually ensure that the program exists by adding it to nativeBuildInputs.

Would this be a problem for user-space Polykey?

Remember we have:

  1. System deployed Polykey - system configuration service
  2. User deployed Polykey - home manager service
  3. Project deployed Polykey?

A command running by itself without an agent - I wonder how that should work?

Copy link
Member

Choose a reason for hiding this comment

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

@tegefaulkes @aryanjassal I want to ensure that our secrets env is foolproof when we have this running...

And by bootstrapping PK from PK... need to examine all the potential problems.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll create a new issue for discussing the spec of the secrets env command changes. There are things that need to be hashed out.

Copy link
Contributor

Choose a reason for hiding this comment

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

This should just be Polykey-CLI, no need for :..

This is being tracked in #312

@CMCDragonkai
Copy link
Member

Where's the issue?

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

Successfully merging this pull request may close these issues.

4 participants