Open hculea opened 1 year ago
Pulumi also falls in this category. We have our own hosted platform, but we easily support filestate backends, backed by cloud storage of AWS, Google Cloud or Azure.
To keep the provisioning of credentials as a narrow as possible, I would only want to activate the shell plugin for the Pulumi backend in use. E.g. start with a Pulumi credential pointing to a cloud based backend (mapped to PULUMI_BACKEND_URL
. This credential in 1Pwd would only contain a Host
field. Assume this is an AWS S3 based backend:
Host: s3://<bucketname>
In such case, I want to allow the AWS shell plugin, because that plugin will provide me with the proper AWS credentials.
One way to do this is to have an additional field: extra plugins
which list the names of the plugin(s) it depends on. Based on this field value, op
adds these plugin(s) to the (de)provisioning flow before/after running the pulumi
.
op CLI version
2.14.0
Goal or desired behavior
Multiple tools that we currently have (or can easily add) plugins for support multiple backends.
Two examples are Docker (DockerHub, Azure/Google/AWS Container Registries etc.) and NPM (official NPM registry, Gitlab/Github package registries etc.).
Current behavior
At this moment, a plugin is not configurable in terms of its backend.
Different tools achieve this in different ways - it may vary between adding a flag/argument to a different credential recipe all together. We should make sure that the solution we put forward is one that abstracts from the third party binary's mechanics.
Relevant log output
No response