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

feat: support BW_APPID #82

Merged
merged 1 commit into from
Dec 2, 2023
Merged

feat: support BW_APPID #82

merged 1 commit into from
Dec 2, 2023

Conversation

jokajak
Copy link
Contributor

@jokajak jokajak commented Nov 23, 2023

This changeset adds support for the BW_APPID environment variable so that the pod can be uniquely identified making it easier to identify when a new login is detected.

Refs: #81

@jokajak
Copy link
Contributor Author

jokajak commented Nov 23, 2023

I still need to test this change.

@jessebot
Copy link
Collaborator

Thanks for this and your other PR! :)

When it's tested, let us know! Also, be sure to bump the helm chart version here by a patch version:

@jokajak
Copy link
Contributor Author

jokajak commented Nov 24, 2023

I realized that this could likely also be accomplished by storing the ~/.config/Bitwarden\ CLI/` in a PVC.

I'm honestly not sure which approach I would choose.

On the one hand, the PVC results in less data having to be transferred but results in all of the vault contents being persisted to disk.

@jessebot
Copy link
Collaborator

@cloudymax, can you also take a peek at this one? It seems like a dream come true, because we get so many email notifications with how often we tear down and re-create test clusters 😵

I realized that this could likely also be accomplished by storing the ~/.config/Bitwarden\ CLI/` in a PVC.

I'm honestly not sure which approach I would choose.

On the one hand, the PVC results in less data having to be transferred but results in all of the vault contents being persisted to disk.

I feel like accepting a config file is ok, as some users may have robust encrypted drives with otherwise good security. And those that don't, may just benefit from a minor warning in the values.yaml? 🤷

@jessebot
Copy link
Collaborator

Also, is BW_APPID not an official env var? 🤔

@cloudymax
Copy link
Collaborator

Also, is BW_APPID not an official env var? 🤔

doesnt seem to be based on the api spec: https://bitwarden.com/help/vault-management-api/

probably just brute-force regexing a field it would normally auto-generate per session but idk

@jokajak
Copy link
Contributor Author

jokajak commented Nov 24, 2023

I identified that the appId value was generated if it didn't exist or used if it did exist by reviewing the contents of the data.json file.

  1. Start without a data.json
  2. Log into bw vault
  3. Identify that the data.json included a appId key.
  4. Replace data.json with just the appId key defined.
  5. Log into bw vault
  6. Observe that the appId key was the same
  7. Make a guess that the appId field it was bitwarden uses to determine if it's a new login

@cloudymax
Copy link
Collaborator

That makes sense, I'll try to do a test-run with the changes and verify I can get it working on my end as well. Should be able to merge soon 👍


env:
REGISTRY: registry.hub.docker.com
IMAGE_NAME: ${{ github.repository_owner }}/bweso
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
IMAGE_NAME: ${{ github.repository_owner }}/bweso
IMAGE_NAME: jessebot/bweso

The docker image is released under the username and profile called jessebot on docker hub, not small-hack, so this would break if not updated.

Comment on lines 48 to 54
- name: Login to GitHub Container Registry
if: ${{ env.REGISTRY == 'ghcr.io' }}
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure we need this right now.

@@ -48,11 +61,11 @@ jobs:
# build from the ./docker directory in this repo
context: docker
platforms: |
linux/amd64
linux/amd64,linux/arm64
Copy link
Collaborator

Choose a reason for hiding this comment

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

please put this in a separate PR so that we can roll back if it breaks anything.

@jessebot
Copy link
Collaborator

Please bump the chart version and the appVersion in Chart.yaml, so that we can release the new docker image with the new tag and the new helm release has your changes. Please also see our comments on the docker build and push workflow, as these changes would break our existing release process.

@cloudymax
Copy link
Collaborator

The changes are good, but doing proper testing is tricky because there's a few PRs worth of work combined here.

It would be ideal to separate out the work into the following:

  1. A PR to add the modifications to the docker enrtypoint. This way we can cut a new image cleanly without co-mingling work for the helm chart.

  2. A PR to bump the helm chart and app version + add the changes to the values.yaml and template and generate a new README via helm-docs

  3. A PR to make changes to the workflow file

If we can get that done, this should be smooth-sailing. Right now though I would need to build and release your container + fork and modify our argo appsets then rebuild a new cluster etc... to put it through its paces properly. Much easier to just chop it up into bite-sized PRs.

This adds the ability to specify a bitwarden appId that can be used to
consistently identify the service running.

Refs: #81
@jokajak
Copy link
Contributor Author

jokajak commented Nov 28, 2023

I removed all but the changes to the dockerfile for this PR.

My other changes were me attempting to build the image using github actions and I just gave up and pushed an image directly to my docker hub. It's been a while since I tried to do anything with docker hub and github actions. I apologize for the confusing changes.

I'll open a new PR for the arm64 support and for supporting the BW_APPID in the chart.

Copy link
Collaborator

@cloudymax cloudymax left a comment

Choose a reason for hiding this comment

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

Looks good!

@cloudymax cloudymax merged commit 1da6c37 into small-hack:main Dec 2, 2023
1 check passed
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.

3 participants