[Feature Request]: Add "generic" KMS support via KMIP Provider

Overview

Currently, SOps supports several cloud-specific Key Management Systems (AWS KMS, GCP KMS, Azure Key Vault, Huawei Cloud KMS). While these cover the major cloud providers, many users utilize self-hosted or third-party KMS solutions that adhere to the KMIP (Key Management Interoperability Protocol) standard.

Motivation

SOps is powerfully useful and operates at the perfect abstraction level for myself and many others ...

• so for advanced users, exploring future, more decentralized, more delicately balanced security solutions, we naturally want to bring SOps with us.
• and for beginner users, looking for simple, minimal, and understandable ways to securely bootstrap trust, this allows a user to get started with their internal or favored KMS.

Novum

I'm requesting the addition of a generic KMIP master key provider. This would enable SOps to evaluate it's policy using any defined KMIP-compliant provider, such as Infisical, or another KMS provider, without requiring a vendor-specific plugin in each instance.

Advantage

Providing a generic KMIP implementation would:

• Prevent Vendor Lock-in: Users would not be tied to specific cloud provider APIs for secret encryption.
• Support On-Prem/Hybrid Environments: Organizations running air-gapped or on-premises infrastructure often use KMIP-compliant solutions.
• Expand Compatibility: Instead of writing individual drivers for every emerging KMS vendor (like Infisical), a single KMIP implementation provides immediate "basic" compatibility with an entire class of platforms.
• Support the expression of more advanced and varied security operations, from to partially online recovery KMS, to future evolutions of the KMS concept.

Substance

Following the existing patterns for AWS or GCP, the KMIP configuration could be defined in the .sops.yaml file or via command-line flags.

• Example .sops.yaml configuration:

creation_rules:
  # or kmip_v2:
  - kmip:
      - endpoint: "kms.infisical.com:5696"
        key_id: "unique-key-identifier"
        # Optional: Paths to client certificate/key for mutual TLS (mTLS)
        cert: "/path/to/client.crt"
        key: "/path/to/client.key"
        ca_cert: "/path/to/ca.crt"

• Environment Variables:
  • To handle authentication securely, sops could look for:

    SOPS_KMIP_CERT / SOPS_KMIP_KEY
    SOPS_KMIP_ENDPOINT

• Comparison to Existing Providers
  • The workflow would mirror the existing KMS logic:
    • SOps generates a data encryption key (DEK) locally.
    • SOps sends the DEK to the KMIP server via an Encrypt or WrapKey operation.
    • The KMIP server returns the encrypted DEK.
  • SOps stores the encrypted DEK in the file metadata.
• Might be regarded as a secure, standards-compliant (supplemental) alternative to the SOps KeyService, for some use-cases.

Resources

• KMIP Specification: OASIS KMIP Standard
• Infisical KMS Documentation: Infisical KMS Overview
• Go KMIP Library: gemalto/kmip-go (or similar libraries that could be used for implementation).

Thanks

Thanks for SOps - it's brilliant and I hope this proposal can make it better.
I'm available to help test any work toward this end.

Start by reviewing the existing AWS and GCP KMS provider patterns and how .sops.yaml configuration and command-line flags are handled. Compare available Go KMIP libraries, then define how endpoint, key ID, and optional mTLS settings map to the provider. Done means a generic KMIP provider can wrap or encrypt the DEK and store the result in file metadata, with secure authentication configuration.