Skip to content

Add Infisical KMS provider - #88

Open
victorvhs017 wants to merge 3 commits into
libopenstorage:masterfrom
victorvhs017:infisical-kms-integration
Open

Add Infisical KMS provider#88
victorvhs017 wants to merge 3 commits into
libopenstorage:masterfrom
victorvhs017:infisical-kms-integration

Conversation

@victorvhs017

@victorvhs017 victorvhs017 commented Apr 13, 2026

Copy link
Copy Markdown

Summary

  • Add infisical-kms secrets backend that delegates encryption/decryption to Infisical KMS
  • Follows the same pattern as existing KMS integrations (gcloud, ibm, aws)
  • Uses Universal Auth (client-id + client-secret) with automatic token refresh
  • Ciphertext persisted via KVDB-backed PersistenceStore
  • Uses Infisical API directly instead of the Infisical Go SDK to avoid adding new dependencies

…nfisical_kms_integration_test.go`, and `infisical_kms_test.go` files.

- Add support for Infisical in the secrets management system, including methods for putting, getting, and deleting secrets.
- Implement integration tests for full lifecycle operations with Infisical KMS.
…dependency changes, implement `infisical/client.go` for KMS client functionality, and modify tests in `infisical_kms_test.go` to align with new client structure.
@varonix0

Copy link
Copy Markdown

Hi @Adityadan, can we please get a review on this PR? It should be good to go with no new dependencies!

@adityadani adityadani left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

In general this library provides three modes:

  1. Integration with KMS providers that generate a "DEK" which then can be used for encrypting data/credentials etc. -> Vaulttransit, AWS KMS etc
  2. Integration with KMS providers that actually store the secrets used for encryption with them -> Vault, Azure KV etc
  3. Google Cloud is another mode and a special case which is similar to what you have implemented which is to encrypt the provided data and store it in the persistence store. But it then supports two KeyContexts: PublicData and CustomData.

Which model suits Infisical better? And if it is 3. can we honor PublicData and CustomData behavior similar to what has been done in Google Cloud so that the clients of this library do not see any changes?

Comment thread infisical/client.go
Comment thread infisical/client.go
Comment thread infisical/infisical_kms.go Outdated
Comment thread infisical/infisical_kms.go Outdated
…ty in `client_test.go`, covering authentication retries, error handling, and secure URL validation.
@victorvhs017

Copy link
Copy Markdown
Author

In general this library provides three modes:

  1. Integration with KMS providers that generate a "DEK" which then can be used for encrypting data/credentials etc. -> Vaulttransit, AWS KMS etc
  2. Integration with KMS providers that actually store the secrets used for encryption with them -> Vault, Azure KV etc
  3. Google Cloud is another mode and a special case which is similar to what you have implemented which is to encrypt the provided data and store it in the persistence store. But it then supports two KeyContexts: PublicData and CustomData.

Which model suits Infisical better? And if it is 3. can we honor PublicData and CustomData behavior similar to what has been done in Google Cloud so that the clients of this library do not see any changes?

Hey @adityadani, thank you for the review!

The model that suits Infisical is indeed the model 3. I updated the PR to handle PublicData and CustomData behavior as it's done in the Google Cloud provider.

I also addressed all the other comments on the PR.

@victorvhs017
victorvhs017 requested a review from adityadani May 14, 2026 22:30

@adityadani adityadani left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

The new changes look good.
The clientSecret is still being sent as plainText over HTTP. If that is expected in the Infisical KMS product, please add that as a comment. Looks good to merge once that is addressed.

@varonix0

Copy link
Copy Markdown

The new changes look good. The clientSecret is still being sent as plainText over HTTP. If that is expected in the Infisical KMS product, please add that as a comment. Looks good to merge once that is addressed.

https://github.com/libopenstorage/secrets/pull/88/changes#diff-9a45dae4434baf2268022432fb8b247d2758334d4a7481e12b33af30c5506d67R44-R46

Should be resolved here!

@victorvhs017

Copy link
Copy Markdown
Author

The new changes look good. The clientSecret is still being sent as plainText over HTTP. If that is expected in the Infisical KMS product, please add that as a comment. Looks good to merge once that is addressed.

Thank you @adityadani! As @varonix0 pointed out, this should already be solved!

@victorvhs017

Copy link
Copy Markdown
Author

Hey @adityadani, I see your approval, but I'm unable to merge it myself. Could you do it, please?

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