support different vault addresses for Hashicorp Vault encryption and decryption

From the current readme, we specify the vault address when encrypting the yaml file.

However, that brings a issue when the vault addresses are different when encrypting and decrypting.

A common use case is that, you port-forward the vault address from a remote k8s cluster to localhost and send encryption request to that. While the data gets decrypted in the cluster, it will send request to the vault address, however which is not localhost.

$ # Substitute this with the address Vault is running on
$ export VAULT_ADDR=http://127.0.0.1:8200

$ # this may not be necessary in case you previously used `vault login` for production use
$ export VAULT_TOKEN=toor

$ # It is required to enable a transit engine if not already done (It is suggested to create a transit engine specifically for sops, in which it is possible to have multiple keys with various permission levels)
$ vault secrets enable -path=sops transit
Success! Enabled the transit secrets engine at: sops/

$ # Then create one or more keys
$ vault write sops/keys/firstkey type=rsa-4096
Success! Data written to: sops/keys/firstkey
 
$ sops --hc-vault-transit $VAULT_ADDR/v1/sops/keys/firstkey vault_example.yml

$ cat <<EOF > .sops.yaml
creation_rules:
        - path_regex: \.dev\.yaml$
          hc_vault_transit_uri: "$VAULT_ADDR/v1/sops/keys/secondkey"
        - path_regex: \.prod\.yaml$
          hc_vault_transit_uri: "$VAULT_ADDR/v1/sops/keys/thirdkey"
EOF

$ sops --verbose -e prod/raw.yaml > prod/encrypted.yaml

The point here is this command:

 sops --hc-vault-transit $VAULT_ADDR/v1/sops/keys/firstkey vault_example.yml

It will send encryption request to VAULT_ADDR and also write that metadata (the same VAULT_ADDR) into encrypted file.

It would be great if we support different vault addresses for Hashicorp Vault encryption and decryption.

Thanks!

Start with the README's HashiCorp Vault section and the --hc-vault-transit entry point. Trace how hc_vault_transit_uri is recorded during encryption and later used for decryption, then identify how separate addresses could be configured. Done means an encrypted file can use one Vault address for encryption and another for decryption, with coverage for the documented workflow.