[1password provider] improve performance

[dschaller]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

At the moment the 1password provider is a bit on the slow side. This is especially noticeable when composing an environment using other environment all defining 1password providers (even if it's the same service account) or when attempting to resolve a large number of secrets.

The slow client initialization time is something we have improved upon by cold loading the wasm module on boot but there is still a cost when creating new 1password clients as the credential exchange still takes time (~2 seconds on average). The slow secret resolution is primarily due to the go sdk using a shared wasm core which can only execute one function at a time. This means that each secret must be resolved serially and on average each of these resolve requests takes ~500ms. With a large number of secrets this can easily go longer than the request timeout threshold.

The 1password go sdk uses the extism go sdk for it's runtime which recently added support for spawning instances of the compiled plugin to make concurrency possible. 1Password/onepassword-sdk-go#165 adds this support to the 1password go sdk but it would only be available in go which is not ideal from a maintenance perspective for the 1password team.

The 1password team is working on adding a bulk api (see 1Password/onepassword-sdk-go#38) that should help a lot with this.

Affected area/feature

1password-provider

[dschaller]

This should be fixed in the latest release of the 1password provider which has been switched onto the bulk API provided by the 1password SDK

[pulumi-bot]

Cannot close issue:

• does not have required labels: resolution/

Please fix these problems and try again.