clarification on uploading a provider about boring-registry HOT 6 CLOSED

hi @oliviermichaelis , thanks for your quick response,
let me explain a bit more the situation :

• we deployed a boring-registry on k8s and we exposed it via an ingress
• my question is whether ./boring-registry upload can work from my local machine to upload a module to the distant boring-registry.
  I hope it's clear .

from boring-registry.

Hi @ilyesAj !

1. I'm not sure what you mean by distant vs local in your question. boring-registry does not need to run on the same machine as Terraform. It could for example run in the cloud, while Terraform runs on your local machine for example. Maybe you could restate your question, so that I can answer it better :)
2. You're right, it's currently not possible yet. I think I might give implementing this a shot this evening

from boring-registry.

Thanks, it's a lot clearer now.
The upload command actually uploads the modules directly to your storage backend (S3, GCS, MinIO). This means that you need to pass valid credentials for the storage backend to the binary when uploading modules.

Edit:
You could for example run boring-registry upload --recursive=true . in your CI/CD system to recursively upload all modules. Credentials can be passed to the binary with AWS_ACCESS_KEY_ID=xxx environment variables for example. Hope this helps :)

from boring-registry.

yep thanks, but I think boring-registry should be the only one accessing/managing S3 bucket. So I as a user I just need to authenticate via static token to boring registry and boring registry will make internally the calls to s3 alongside with some checks to avoid conflicts on upload.

from boring-registry.

That would definitely be nice! The implementation would probably be more complex, though.
With the current approach, we can leverage the sophisticated identity and access management services from cloud vendors for uploading modules/providers to the object storage with little effort. In contrast to relying on the static token and the boring-registries implementation of authorization.

Right now, the boring-registry can only serve what's already there. When attackers gain access to one of boring-registry's static auth token, they can only use what's already there, and not inject arbitrary modules to escalate privileges or exfiltrate data. I guess that's part of what makes the boring-registry boring :)

from boring-registry.

agree, it's a different approach ;)

from boring-registry.