GoogleCloudPlatform / berglas

A tool for managing secrets on Google Cloud
https://cloud.google.com/secret-manager
Apache License 2.0
1.24k stars 96 forks source link

Future support for other runtimes? #19

Closed theomessin closed 4 years ago

theomessin commented 5 years ago

Are there any plans to extend support to other runtimes (Python or Node)?

sethvargo commented 5 years ago

Hey @theomessin

It's been discussed 😄. In short, it's challenging to re-implement the exact same crypto algorithms across languages. Other languages require binding to openssl or a system library, making them far less portable.

We're exploring the possibility of embedding the berglas binary inside of other clients, but the general recommendation today is to run berglas exec for non-Go apps. Sorry 😦

theomessin commented 5 years ago

Hey @sethvargo. Thanks for replying!

So, just to clarify: we like the CLI tool, we'd like to be able to use the Berglas managed secrets in our Python Google Cloud Functions. Are you saying that this would be quite hard to do?

Currently we use the Python library for Google Cloud KMS to decrypt ad-hoc stored secrets and the code is quite simple.

sethvargo commented 5 years ago

Hi @theomessin

Yes 😄 . Berglas doesn't just use KMS (see Implementation). In short, Berglas generates a unique key for each piece of data. That key encrypts the data locally on your machine. Then we use Cloud KMS to encrypt that key. As such, we'd have to replicate the envelope encryption in every language (hence my earlier comment about binding to openssl, etc).

theomessin commented 5 years ago

Fair enough. That makes more sense. Thanks! :smile:

aausch commented 5 years ago

bump

sethvargo commented 5 years ago

There's a python one now: https://pypi.org/project/berglas-python/

maroux commented 5 years ago

I can add this support to berglas main once GoogleCloudPlatform/berglas#43 is tested and merged. Then, at least for GAE flex we'd be able to move to library usage rather than exec - however not sure if all that is worth it.

maroux commented 5 years ago

I think pycryptodome supports everything berglas needs without using C extensions.

maroux commented 5 years ago

I have a working POC for the python library here - https://github.com/maroux/berglas-python/pull/1..

@sethvargo let me know if you'd be interested in merging that repo here (not sure how Travis will work).

sethvargo commented 5 years ago

@maroux did you see the python one above? https://pypi.org/project/berglas-python/

maroux commented 5 years ago

@sethvargo just looked - it uses cryptography so binds to openssl etc and doesn't provide an auto resolver.

maroux commented 5 years ago

I created GoogleCloudPlatform/berglas#46 that adds examples of using the python library.

chrisbenincasa commented 5 years ago

I've written a Node library similar to the Python one, which enables use of the NodeJS runtime in Cloud Functions with Berglas: https://github.com/chrisbenincasa/berglas-node

cm-igarashi-ryosuke commented 4 years ago

As for App Engine (Standard), we were able to place berglas binaries by using Cloud Build in the previous stage.

pre_cloudbuild.yaml

Since App Engine cannot place a file named cloudbuild.yaml in the root directory, the name of cloudbuild.yaml is changed to pre_cloudbuild.yaml.

steps:
  - name: gcr.io/cloud-builders/curl
    args:
      - https://storage.googleapis.com/berglas/master/linux_amd64/berglas
      - --output
      - berglas
  - name: ubuntu
    args:
      - chmod
      - "777"
      - berglas
  - name: gcr.io/cloud-builders/gcloud
    args:
      - app
      - deploy
      - app.yaml

app.yaml

runtime: nodejs10
entrypoint: ./berglas exec -- npm start
env_variables:
  HOGE: berglas://{BUCKET_ID}/hoge

What do you think about this method?

Alternatively, if you deploy berglas binaries in the root directory in advance, the previous Cloud Build is not required.

PeteFein commented 4 years ago

it'd be nice to add a link to the python implementation to the README, i only found this ticket by chance

github-actions[bot] commented 4 years ago

This issue is stale because it has been open for 14 days with no activity. It will automatically close after 7 more days of inactivity.

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.