[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-4794":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":34,"readmeContent":35,"aiSummary":36,"trendingCount":16,"starSnapshotCount":16,"syncStatus":37,"lastSyncTime":38,"discoverSource":39},4794,"sops","getsops\u002Fsops","getsops","Simple and flexible tool for managing secrets","https:\u002F\u002Fgetsops.io",null,"Go",22059,1035,120,363,0,4,61,329,36,107.05,"Mozilla Public License 2.0",false,"main",[26,27,28,29,30,31,32,33,5],"aws","azure","devops","gcp","pgp","secret-distribution","secret-management","security","2026-06-12 04:00:22","SOPS: Secrets OPerationS\n========================\n\n**SOPS** is an editor of encrypted files that supports YAML, JSON, ENV, INI and BINARY\nformats and encrypts with AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age, and PGP.\n(`demo \u003Chttps:\u002F\u002Fwww.youtube.com\u002Fwatch?v=YTEVyLXFiq0>`_)\n\n.. image:: https:\u002F\u002Fi.imgur.com\u002FX0TM5NI.gif\n\n------------\n\n.. image:: https:\u002F\u002Fpkg.go.dev\u002Fbadge\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Fv3.svg\n    :target: https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Fv3\n\nDownload\n--------\n\nStable release\n~~~~~~~~~~~~~~\nBinaries and packages of the latest stable release are available at `https:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Freleases \u003Chttps:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Freleases>`_.\n\nDevelopment branch\n~~~~~~~~~~~~~~~~~~\nFor the adventurous, unstable features are available in the `main` branch, which you can install from source:\n\n.. code:: bash\n\n    $ mkdir -p $GOPATH\u002Fsrc\u002Fgithub.com\u002Fgetsops\u002Fsops\u002F\n    $ git clone https:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops.git $GOPATH\u002Fsrc\u002Fgithub.com\u002Fgetsops\u002Fsops\u002F\n    $ cd $GOPATH\u002Fsrc\u002Fgithub.com\u002Fgetsops\u002Fsops\u002F\n    $ make install\n\n(requires Go >= 1.25)\n\nIf you don't have Go installed, set it up with:\n\n.. code:: bash\n\n    $ {apt,yum,brew} install golang\n    $ echo 'export GOPATH=~\u002Fgo' >> ~\u002F.bashrc\n    $ source ~\u002F.bashrc\n    $ mkdir $GOPATH\n\nOr whatever variation of the above fits your system and shell.\n\nTo use **SOPS** as a library, take a look at the `decrypt package \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Fv3\u002Fdecrypt>`_.\n\n.. sectnum::\n.. contents:: Table of Contents\n\nUsage\n-----\n\nFor a quick presentation of SOPS, check out this Youtube tutorial:\n\n.. image:: https:\u002F\u002Fimg.youtube.com\u002Fvi\u002FV2PRhxphH2w\u002F0.jpg\n   :target: https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=V2PRhxphH2w\n\nIf you're using AWS KMS, create one or multiple master keys in the IAM console\nand export them, comma separated, in the **SOPS_KMS_ARN** env variable. It is\nrecommended to use at least two master keys in different regions.\n\n.. code:: bash\n\n    export SOPS_KMS_ARN=\"arn:aws:kms:us-east-1:656532927350:key\u002F920aff2e-c5f1-4040-943a-047fa387b27e,arn:aws:kms:ap-southeast-1:656532927350:key\u002F9006a8aa-0fa6-4c14-930e-a2dfb916de1d\"\n\nSOPS uses `aws-sdk-go-v2 \u003Chttps:\u002F\u002Fgithub.com\u002Faws\u002Faws-sdk-go-v2>`_ to communicate with AWS KMS. It will automatically\nread the credentials from the ``~\u002F.aws\u002Fcredentials`` file which can be created with the ``aws configure`` command.\n\nAn example of the ``~\u002F.aws\u002Fcredentials`` file is shown below:\n\n.. code:: sh\n\n    $ cat ~\u002F.aws\u002Fcredentials\n    [default]\n    aws_access_key_id = AKI.....\n    aws_secret_access_key = mw......\n\nIn addition to the ``~\u002F.aws\u002Fcredentials`` file, you can also use the ``AWS_ACCESS_KEY_ID`` and ``AWS_SECRET_ACCESS_KEY``\nenvironment variables to specify your credentials:\n\n.. code:: bash\n\n    export AWS_ACCESS_KEY_ID=\"AKI......\"\n    export AWS_SECRET_ACCESS_KEY=\"mw......\"\n\nFor more information and additional environment variables, see\n`specifying credentials \u003Chttps:\u002F\u002Fdocs.aws.amazon.com\u002Fsdk-for-go\u002Fv2\u002Fdeveloper-guide\u002Fconfigure-gosdk.html#specifying-credentials>`_.\n\nIf you want to use PGP, export the fingerprints of the public keys, comma\nseparated, in the **SOPS_PGP_FP** env variable.\n\n.. code:: bash\n\n    export SOPS_PGP_FP=\"85D77543B3D624B63CEA9E6DBC17301B491B3F21,E60892BB9BD89A69F759A1A0A3D652173B763E8F\"\n\nNote: you can use both PGP and KMS simultaneously.\n\nThen simply call ``sops edit`` with a file path as argument. It will handle the\nencryption\u002Fdecryption transparently and open the cleartext file in an editor\n\n.. code:: sh\n\n    $ sops edit mynewtestfile.yaml\n    mynewtestfile.yaml doesn't exist, creating it.\n    please wait while an encryption key is being generated and stored in a secure fashion\n    file written to mynewtestfile.yaml\n\nEditing will happen in whatever ``$SOPS_EDITOR`` or ``$EDITOR`` is set to, or, if it's\nnot set, in vim, nano, or vi.\nKeep in mind that SOPS will wait for the editor to exit, and then try to reencrypt\nthe file. Some GUI editors (atom, sublime) spawn a child process and then exit\nimmediately. They usually have an option to wait for the main editor window to be\nclosed before exiting. See `#127 \u003Chttps:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Fissues\u002F127>`_ for\nmore information.\n\nThe resulting encrypted file looks like this:\n\n.. code:: yaml\n\n    myapp1: ENC[AES256_GCM,data:Tr7o=,iv:1=,aad:No=,tag:k=]\n    app2:\n        db:\n            user: ENC[AES256_GCM,data:CwE4O1s=,iv:2k=,aad:o=,tag:w==]\n            password: ENC[AES256_GCM,data:p673w==,iv:YY=,aad:UQ=,tag:A=]\n        # private key for secret operations in app2\n        key: |-\n            ENC[AES256_GCM,data:Ea3kL5O5U8=,iv:DM=,aad:FKA=,tag:EA==]\n    an_array:\n        - ENC[AES256_GCM,data:v8jQ=,iv:HBE=,aad:21c=,tag:gA==]\n        - ENC[AES256_GCM,data:X10=,iv:o8=,aad:CQ=,tag:Hw==]\n        - ENC[AES256_GCM,data:KN=,iv:160=,aad:fI4=,tag:tNw==]\n    sops:\n        kms:\n            - created_at: 1441570389.775376\n              enc: CiC....Pm1Hm\n              arn: arn:aws:kms:us-east-1:656532927350:key\u002F920aff2e-c5f1-4040-943a-047fa387b27e\n            - created_at: 1441570391.925734\n              enc: Ci...awNx\n              arn: arn:aws:kms:ap-southeast-1:656532927350:key\u002F9006a8aa-0fa6-4c14-930e-a2dfb916de1d\n        pgp:\n            - fp: 85D77543B3D624B63CEA9E6DBC17301B491B3F21\n              created_at: 1441570391.930042\n              enc: |\n                  -----BEGIN PGP MESSAGE-----\n                  hQIMA0t4uZHfl9qgAQ\u002F\u002FUvGAwGePyHuf2\u002FzayWcloGaDs0MzI+zw6CmXvMRNPUsA\n                  ...=oJgS\n                  -----END PGP MESSAGE-----\n\nA copy of the encryption\u002Fdecryption key is stored securely in each KMS and PGP\nblock. As long as one of the KMS or PGP method is still usable, you will be able\nto access your data.\n\nTo decrypt a file in a ``cat`` fashion, use the ``-d`` flag:\n\n.. code:: sh\n\n    $ sops decrypt mynewtestfile.yaml\n\nSOPS encrypted files contain the necessary information to decrypt their content.\nAll a user of SOPS needs is valid AWS credentials and the necessary\npermissions on KMS keys.\n\nGiven that, the only command a SOPS user needs is:\n\n.. code:: sh\n\n    $ sops edit \u003Cfile>\n\n`\u003Cfile>` will be opened, decrypted, passed to a text editor (vim by default),\nencrypted if modified, and saved back to its original location. All of these\nsteps, apart from the actual editing, are transparent to the user.\n\nThe order in which available decryption methods are tried can be specified with\n``--decryption-order`` option or **SOPS_DECRYPTION_ORDER** environment variable\nas a comma separated list. The default order is ``age,pgp``. Offline methods are\ntried first and then the remaining ones.\n\nTest with the dev PGP key\n~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you want to test **SOPS** without having to do a bunch of setup, you can use\nthe example files and pgp key provided with the repository::\n\n    $ git clone https:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops.git\n    $ cd sops\n    $ gpg --import pgp\u002Fsops_functional_tests_key.asc\n    $ sops edit example.yaml\n\nThis last step will decrypt ``example.yaml`` using the test private key.\n\nEncrypting with GnuPG subkeys\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you want to encrypt with specific GnuPG subkeys, it does not suffice to provide the\nexact key ID of the subkey to SOPS, since GnuPG might use *another* subkey instead\nto encrypt the file key with. To force GnuPG to use a specific subkey, you need to\nappend ``!`` to the key's fingerprint.\n\n.. code:: yaml\n\n    creation_rules:\n        - pgp: >-\n            85D77543B3D624B63CEA9E6DBC17301B491B3F21!,\n            E60892BB9BD89A69F759A1A0A3D652173B763E8F!\n\nPlease note that this is only passed on correctly to GnuPG since SOPS 3.9.3.\n\nEncrypting using age\n~~~~~~~~~~~~~~~~~~~~\n\n`age \u003Chttps:\u002F\u002Fage-encryption.org\u002F>`_ is a simple, modern, and secure tool for\nencrypting files. It's recommended to use age over PGP, if possible.\n\nYou can encrypt a file for one or more age recipients (comma separated) using\nthe ``--age`` option or the **SOPS_AGE_RECIPIENTS** environment variable:\n\n.. code:: sh\n\n    $ sops encrypt --age age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw test.yaml > test.enc.yaml\n\nWhen decrypting a file with the corresponding identity, SOPS will look for a\ntext file name ``keys.txt`` located in a ``sops`` subdirectory of your user\nconfiguration directory. \n\n- **Linux**\n\n  - Looks for ``keys.txt`` in ``$XDG_CONFIG_HOME\u002Fsops\u002Fage\u002Fkeys.txt``;\n  - Falls back to ``$HOME\u002F.config\u002Fsops\u002Fage\u002Fkeys.txt`` if ``$XDG_CONFIG_HOME`` isn’t set.\n\n- **macOS**\n\n  - Looks for ``keys.txt`` in ``$XDG_CONFIG_HOME\u002Fsops\u002Fage\u002Fkeys.txt``;\n  - Falls back to ``$HOME\u002FLibrary\u002FApplication Support\u002Fsops\u002Fage\u002Fkeys.txt`` if ``$XDG_CONFIG_HOME`` isn’t set.\n\n- **Windows**\n\n  - Looks for ``keys.txt`` in `%AppData%\\\\sops\\\\age\\\\keys.txt``.\n\nYou can override the default lookup by:\n\n- setting the environment variable **SOPS_AGE_KEY_FILE**;\n- setting the **SOPS_AGE_KEY** environment variable;\n- providing a command to output the age keys by setting the **SOPS_AGE_KEY_CMD** environment variable.\n  This command can read the age recipient for which to return the private key from the **SOPS_AGE_RECIPIENT** environment variable.\n\nThe contents of this key file should be a list of age X25519 identities, one\nper line. Lines beginning with ``#`` are considered comments and ignored. Each\nidentity will be tried in sequence until one is able to decrypt the data.\n\nEncrypting with SSH keys via age is also supported by SOPS. You can use SSH public keys\n(\"ssh-ed25519 AAAA...\", \"ssh-rsa AAAA...\") as age recipients when encrypting a file.\n\nWhen decrypting a file, SOPS will attempt to source the SSH private key as follows:\n\n- From the path specified in environment variable **SOPS_AGE_SSH_PRIVATE_KEY_FILE**.\n- From the output of the command specified in environment variable **SOPS_AGE_SSH_PRIVATE_KEY_CMD**.\n\n   .. note:: The output of this command must provide a key that is not password protected.\n\n- From ``~\u002F.ssh\u002Fid_ed25519``.\n- From ``~\u002F.ssh\u002Fid_rsa``.\n\nNote that only ``ssh-rsa`` and ``ssh-ed25519`` are supported.\n\nA list of age recipients can be added to the ``.sops.yaml``:\n\n.. code:: yaml\n\n    creation_rules:\n        - age: >-\n            age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c,\n            age1qe5lxzzeppw5k79vxn3872272sgy224g2nzqlzy3uljs84say3yqgvd0sw\n\nIt is also possible to use ``updatekeys``, when adding or removing age recipients. For example:\n\n.. code:: sh\n\n  $ sops updatekeys secret.enc.yaml\n  2022\u002F02\u002F09 16:32:02 Syncing keys for file \u002Fiac\u002Fsolution1\u002Fsecret.enc.yaml\n  The following changes will be made to the file's groups:\n  Group 1\n      age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c\n  +++ age1qe5lxzzeppw5k79vxn3872272sgy224g2nzqlzy3uljs84say3yqgvd0sw\n  Is this okay? (y\u002Fn):y\n  2022\u002F02\u002F09 16:32:04 File \u002Fiac\u002Fsolution1\u002Fsecret.enc.yaml synced with new keys\n  \nEncrypting using GCP KMS\n~~~~~~~~~~~~~~~~~~~~~~~~\nGCP KMS has support for authorization with the use of `Application Default Credentials\n\u003Chttps:\u002F\u002Fdevelopers.google.com\u002Fidentity\u002Fprotocols\u002Fapplication-default-credentials>`_ and using an OAuth 2.0 token.\nApplication default credentials precedes the use of access token.\n\nUsing Application Default Credentials you can authorize by doing this:\n\nIf you already logged in using\n\n.. code:: sh\n\n    $ gcloud auth login\n\nyou can enable application default credentials using the sdk:\n\n.. code:: sh\n\n    $ gcloud auth application-default login\n\nUsing OAauth tokens you can authorize by doing this:\n\n.. code:: sh\n    \n    $ export GOOGLE_OAUTH_ACCESS_TOKEN=\u003Cyour access token>\n\nOr if you are logged in you can authorize by generating an access token:\n\n.. code:: sh\n\n    $ export GOOGLE_OAUTH_ACCESS_TOKEN=\"$(gcloud auth print-access-token)\"\n\nBy default, SOPS uses the gRPC client to communicate with GCP KMS. You can optionally\nswitch to the REST client by setting the ``SOPS_GCP_KMS_CLIENT_TYPE`` environment variable:\n\n.. code:: sh\n\n    $ export SOPS_GCP_KMS_CLIENT_TYPE=rest  # Use REST client\n    $ export SOPS_GCP_KMS_CLIENT_TYPE=grpc  # Use gRPC client (default)\n\nFor sovereign cloud environments that expose a GCP-compatible KMS API at a\nnon-standard endpoint (e.g. S3NS\u002FThales TPC: ``cloudkms.s3nsapis.fr``),\nyou can override the endpoint or the universe domain:\n\n.. code:: sh\n\n    # Override the KMS endpoint directly\n    $ export SOPS_GCP_KMS_ENDPOINT=cloudkms.example.com:443\n\n    # Or derive the endpoint from the universe domain (cloudkms.\u003Cdomain>:443)\n    $ export SOPS_GCP_KMS_UNIVERSE_DOMAIN=example.com\n\n.. note:: ``SOPS_GCP_KMS_ENDPOINT`` takes precedence over ``SOPS_GCP_KMS_UNIVERSE_DOMAIN`` if both are set.\n\nEncrypting\u002Fdecrypting with GCP KMS requires a KMS ResourceID. You can use the\ncloud console the get the ResourceID or you can create one using the gcloud\nsdk:\n\n.. code:: sh\n\n    $ gcloud kms keyrings create sops --location global\n    $ gcloud kms keys create sops-key --location global --keyring sops --purpose encryption\n    $ gcloud kms keys list --location global --keyring sops\n\n    # you should see\n    NAME                                                                   PURPOSE          PRIMARY_STATE\n    projects\u002Fmy-project\u002Flocations\u002Fglobal\u002FkeyRings\u002Fsops\u002FcryptoKeys\u002Fsops-key ENCRYPT_DECRYPT  ENABLED\n\nNow you can encrypt a file using::\n\n    $ sops encrypt --gcp-kms projects\u002Fmy-project\u002Flocations\u002Fglobal\u002FkeyRings\u002Fsops\u002FcryptoKeys\u002Fsops-key test.yaml > test.enc.yaml\n\nAnd decrypt it using::\n\n     $ sops decrypt test.enc.yaml\n\nEncrypting using Azure Key Vault\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe Azure Key Vault integration uses the\n`default credential chain \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002FAzure\u002Fazure-sdk-for-go\u002Fsdk\u002Fazidentity#DefaultAzureCredential>`_\nwhich tries several authentication methods, in this order:\n\n1. `Environment credentials \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002FAzure\u002Fazure-sdk-for-go\u002Fsdk\u002Fazidentity#EnvironmentCredential>`_\n\n   i. Service Principal with Client Secret\n   ii. Service Principal with Certificate\n   iii. User with username and password\n   iv. Configuration for multi-tenant applications\n\n2. `Workload Identity credentials \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002FAzure\u002Fazure-sdk-for-go\u002Fsdk\u002Fazidentity#WorkloadIdentityCredential>`_\n3. `Managed Identity credentials \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002FAzure\u002Fazure-sdk-for-go\u002Fsdk\u002Fazidentity#ManagedIdentityCredential>`_\n4. `Azure CLI credentials \u003Chttps:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002FAzure\u002Fazure-sdk-for-go\u002Fsdk\u002Fazidentity#AzureCLICredential>`_\n\nFor example, you can use a Service Principal with the following environment variables:\n\n.. code:: bash\n\n    AZURE_TENANT_ID\n    AZURE_CLIENT_ID\n    AZURE_CLIENT_SECRET\n\nYou can create a Service Principal using the CLI like this:\n\n.. code:: sh\n\n    $ az ad sp create-for-rbac -n my-keyvault-sp\n\n    {\n        \"appId\": \"\u003Csome-uuid>\",\n        \"displayName\": \"my-keyvault-sp\",\n        \"name\": \"http:\u002F\u002Fmy-keyvault-sp\",\n        \"password\": \"\u003Crandom-string>\",\n        \"tenant\": \"\u003Ctenant-uuid>\"\n    }\n\nThe `appId` is the client ID, and the `password` is the client secret.\n\nEncrypting\u002Fdecrypting with Azure Key Vault requires the resource identifier for\na key. This has the following form::\n\n    https:\u002F\u002F${VAULT_URL}\u002Fkeys\u002F${KEY_NAME}\u002F${KEY_VERSION}\n\nYou can omit the version, and have just a trailing slash, and this will use\nwhatever the latest version of the key is::\n\n    https:\u002F\u002F${VAULT_URL}\u002Fkeys\u002F${KEY_NAME}\u002F\n\nTo create a Key Vault and assign your service principal permissions on it\nfrom the commandline:\n\n.. code:: sh\n\n    # Create a resource group if you do not have one:\n    $ az group create --name sops-rg --location westeurope\n    # Key Vault names are globally unique, so generate one:\n    $ keyvault_name=sops-$(uuidgen | tr -d - | head -c 16)\n    # Create a Vault, a key, and give the service principal access:\n    $ az keyvault create --name $keyvault_name --resource-group sops-rg --location westeurope\n    $ az keyvault key create --name sops-key --vault-name $keyvault_name --protection software --ops encrypt decrypt\n    $ az keyvault set-policy --name $keyvault_name --resource-group sops-rg --spn $AZURE_CLIENT_ID \\\n        --key-permissions get encrypt decrypt\n    # Read the key id:\n    $ az keyvault key show --name sops-key --vault-name $keyvault_name --query key.kid\n\n    https:\u002F\u002Fsops.vault.azure.net\u002Fkeys\u002Fsops-key\u002Fsome-string\n\n.. note::\n\n  The ``get`` key permission is required when the key version is ommited (for example if the URL ends with a trailing slash). In that case SOPS calls the Azure Key Vault API to resolve the latest key version, which requires the ``get`` permission. If you specifty an explicit key version in the URL you can omit ``get``, but this means you will need to update your configuration every time the key is rotated.\n\nNow you can encrypt a file using::\n\n    $ sops encrypt --azure-kv https:\u002F\u002Fsops.vault.azure.net\u002Fkeys\u002Fsops-key\u002Fsome-string test.yaml > test.enc.yaml\n\nor, without the version::\n\n    $ sops encrypt --azure-kv https:\u002F\u002Fsops.vault.azure.net\u002Fkeys\u002Fsops-key\u002F test.yaml > test.enc.yaml\n\nAnd decrypt it using::\n\n    $ sops decrypt test.enc.yaml\n\n\nEncrypting and decrypting from other programs\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nWhen using ``sops`` in scripts or from other programs, there are often situations where you do not want to write\nencrypted or decrypted data to disk. The best way to avoid this is to pass data to SOPS via stdin, and to let\nSOPS write data to stdout. By default, the encrypt and decrypt operations write data to stdout already. To pass\ndata via stdin, you need to not provide an input filename. For encryption, you also must provide the\n``--filename-override`` option with the file's filename. The filename will be used to determine the input and output\ntypes, and to select the correct creation rule.\n\nThe simplest way to decrypt data from stdin is as follows:\n\n.. code:: sh\n\n    $ cat encrypted-data | sops decrypt > decrypted-data\n\nBy default, ``sops`` determines the input and output format from the provided filename. Since in this case,\nno filename is provided, ``sops`` will use the binary store which expects JSON input and outputs binary data\non decryption. This is often not what you want.\n\nTo avoid this, you can either provide a filename with ``--filename-override``, or explicitly control\nthe input and output formats by passing ``--input-type`` and ``--output-type`` as appropriate:\n\n.. code:: sh\n\n    $ cat encrypted-data | sops decrypt --filename-override filename.yaml > decrypted-data\n    $ cat encrypted-data | sops decrypt --input-type yaml --output-type yaml > decrypted-data\n\nIn both cases, ``sops`` will assume that the data you provide is in YAML format, and will encode the decrypted\ndata in YAML as well. The second form allows to use different formats for input and output.\n\nTo encrypt, it is important to note that SOPS also uses the filename to look up the correct creation rule from\n``.sops.yaml``. Therefore, you must provide the ``--filename-override`` parameter which allows you to tell\nSOPS which filename to use to match creation rules:\n\n.. code:: sh\n\n    $ echo 'foo: bar' | sops encrypt --filename-override path\u002Ffilename.sops.yaml > encrypted-data\n\nSOPS will find a matching creation rule for ``path\u002Ffilename.sops.yaml`` in ``.sops.yaml`` and use that one to\nencrypt the data from stdin. This filename will also be used to determine the input and output store. As always,\nthe input store type can be adjusted by passing ``--input-type``, and the output store type by passing\n``--output-type``:\n\n.. code:: sh\n\n    $ echo foo=bar | sops encrypt --filename-override path\u002Ffilename.sops.yaml --input-type dotenv > encrypted-data\n\n\nEncrypting using Hashicorp Vault\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nWe assume you have an instance (or more) of Vault running and you have privileged access to it. For instructions on how to deploy a secure instance of Vault, refer to Hashicorp's official documentation.\n\nTo easily deploy Vault locally: (DO NOT DO THIS FOR PRODUCTION!!!) \n\n.. code:: sh\n\n    $ docker run -d -p8200:8200 vault:1.2.0 server -dev -dev-root-token-id=toor\n\n\n.. code:: sh\n\n    $ # Substitute this with the address Vault is running on\n    $ export VAULT_ADDR=http:\u002F\u002F127.0.0.1:8200 \n\n    $ # this may not be necessary in case you previously used `vault login` for production use\n    $ export VAULT_TOKEN=toor \n    \n    $ # to check if Vault started and is configured correctly\n    $ vault status\n    Key             Value\n    ---             -----\n    Seal Type       shamir\n    Initialized     true\n    Sealed          false\n    Total Shares    1\n    Threshold       1\n    Version         1.2.0\n    Cluster Name    vault-cluster-618cc902\n    Cluster ID      e532e461-e8f0-1352-8a41-fc7c11096908\n    HA Enabled      false\n\n    $ # 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)\n    $ vault secrets enable -path=sops transit\n    Success! Enabled the transit secrets engine at: sops\u002F\n\n    $ # Then create one or more keys\n    $ vault write sops\u002Fkeys\u002Ffirstkey type=rsa-4096\n    Success! Data written to: sops\u002Fkeys\u002Ffirstkey\n\n    $ vault write sops\u002Fkeys\u002Fsecondkey type=rsa-2048\n    Success! Data written to: sops\u002Fkeys\u002Fsecondkey\n\n    $ vault write sops\u002Fkeys\u002Fthirdkey type=chacha20-poly1305\n    Success! Data written to: sops\u002Fkeys\u002Fthirdkey\n\n    $ sops encrypt --hc-vault-transit $VAULT_ADDR\u002Fv1\u002Fsops\u002Fkeys\u002Ffirstkey vault_example.yml\n\n    $ cat \u003C\u003CEOF > .sops.yaml\n    creation_rules:\n        - path_regex: \\.dev\\.yaml$\n          hc_vault_transit_uri: \"$VAULT_ADDR\u002Fv1\u002Fsops\u002Fkeys\u002Fsecondkey\"\n        - path_regex: \\.prod\\.yaml$\n          hc_vault_transit_uri: \"$VAULT_ADDR\u002Fv1\u002Fsops\u002Fkeys\u002Fthirdkey\"\n    EOF\n\n    $ sops encrypt --verbose prod\u002Fraw.yaml > prod\u002Fencrypted.yaml\n\nRestricting HC Vault servers that SOPS can talk to\n**************************************************\n\nIf you want to restrict which HC Vault servers SOPS is allowed to talk to, you can set the ``SOPS_HC_VAULT_ALLOWLIST`` environment variable.\nWhen set to ``all`` (the default value), there is no restriction.\nWhen set to ``none``, SOPS will not allow any access to HC Vault servers for decryption or encryption.\n\nWhen set to any other value, this value will be interpreted as a comma-separated list of strings.\nIf SOPS attempts to contact a vault URL that starts with one of these strings, SOPS will attempt to contact that URL.\nIf there is no matching prefix in ``SOPS_HC_VAULT_ALLOWLIST``, SOPS will not contact that URL.\n\nEncrypting using HuaweiCloud KMS\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe HuaweiCloud KMS integration uses the\n`default credential provider chain \u003Chttps:\u002F\u002Fgithub.com\u002Fhuaweicloud\u002Fhuaweicloud-sdk-go-v3\u002Fblob\u002Fmaster\u002Fcore\u002Fauth\u002Fprovider\u002Fprovider.go>`_\nwhich tries several authentication methods, in this order:\n\n1. Environment variables: ``HUAWEICLOUD_SDK_AK``, ``HUAWEICLOUD_SDK_SK``, ``HUAWEICLOUD_SDK_PROJECT_ID``\n2. Credentials file at ``~\u002F.huaweicloud\u002Fcredentials``\n3. Instance metadata (when running on HuaweiCloud instances)\n\nFor example, you can use environment variables:\n\n.. code:: bash\n\n    export HUAWEICLOUD_SDK_AK=\"your-access-key\"\n    export HUAWEICLOUD_SDK_SK=\"your-secret-key\"\n    export HUAWEICLOUD_SDK_PROJECT_ID=\"your-project-id\"\n\nAlternatively, you can create a credentials file at ``~\u002F.huaweicloud\u002Fcredentials``:\n\n.. code:: sh\n\n    $ cat ~\u002F.huaweicloud\u002Fcredentials\n    [default]\n    ak = your-access-key\n    sk = your-secret-key\n    project_id = your-project-id\n\nEncrypting\u002Fdecrypting with HuaweiCloud KMS requires a KMS key ID in the format\n``region:key-uuid``. You can get the key ID from the HuaweiCloud console or using\nthe HuaweiCloud API. The key ID format is ``region:key-uuid`` where:\n\n- ``region`` is the HuaweiCloud region (e.g., ``tr-west-1``, ``cn-north-1``)\n- ``key-uuid`` is the UUID of the KMS key (e.g., ``abc12345-6789-0123-4567-890123456789``)\n\nNow you can encrypt a file using:\n\n.. code:: sh\n\n    $ sops encrypt --hckms tr-west-1:abc12345-6789-0123-4567-890123456789 test.yaml > test.enc.yaml\n\nOr using the environment variable:\n\n.. code:: sh\n\n    $ export SOPS_HUAWEICLOUD_KMS_IDS=\"tr-west-1:abc12345-6789-0123-4567-890123456789\"\n    $ sops encrypt test.yaml > test.enc.yaml\n\nAnd decrypt it using:\n\n.. code:: sh\n\n    $ sops decrypt test.enc.yaml\n\nYou can also configure HuaweiCloud KMS keys in the ``.sops.yaml`` config file:\n\n.. code:: yaml\n\n    creation_rules:\n        - path_regex: \\.hckms\\.yaml$\n          hckms:\n            - tr-west-1:abc12345-6789-0123-4567-890123456789,tr-west-2:def67890-1234-5678-9012-345678901234\n\nAdding and removing keys\n~~~~~~~~~~~~~~~~~~~~~~~~\n\nWhen creating new files, ``sops`` uses the PGP, KMS and GCP KMS defined in the\ncommand line arguments ``--kms``, ``--pgp``, ``--gcp-kms``, ``--hckms`` or ``--azure-kv``, or from\nthe environment variables ``SOPS_KMS_ARN``, ``SOPS_PGP_FP``, ``SOPS_GCP_KMS_IDS``,\n``SOPS_HUAWEICLOUD_KMS_IDS``, ``SOPS_AZURE_KEYVAULT_URLS``. That information is stored in the file under the\n``sops`` section, such that decrypting files does not require providing those\nparameters again.\n\nMaster PGP and KMS keys can be added and removed from a ``sops`` file in one of\nthree ways:\n\n1. By using a ``.sops.yaml`` file and the ``updatekeys`` command.\n\n2. By using command line flags.\n\n3. By editing the file directly.\n\nThe SOPS team recommends the ``updatekeys`` approach.\n\n\n``updatekeys`` command\n**********************\n\nThe ``updatekeys`` command uses the `.sops.yaml \u003C#using-sops-yaml-conf-to-select-kms-pgp-for-new-files>`_\nconfiguration file to update (add or remove) the corresponding secrets in the\nencrypted file. Note that the example below uses the\n`Block Scalar yaml construct \u003Chttps:\u002F\u002Fyaml-multiline.info\u002F>`_ to build a space\nseparated list.\n\n.. code:: yaml\n\n    creation_rules:\n        - pgp: >-\n            85D77543B3D624B63CEA9E6DBC17301B491B3F21,\n            FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4\n\n.. code:: sh\n\n    $ sops updatekeys test.enc.yaml\n\nSOPS will prompt you with the changes to be made. This interactivity can be\ndisabled by supplying the ``-y`` flag.\n\n``rotate`` command\n******************\n\nThe ``rotate`` command generates a new data encryption key and reencrypt all values\nwith the new key. At the same time, the command line flag ``--add-kms``, ``--add-pgp``,\n``--add-gcp-kms``, ``--add-hckms``, ``--add-azure-kv``, ``--rm-kms``, ``--rm-pgp``, ``--rm-gcp-kms``,\n``--rm-hckms`` and ``--rm-azure-kv`` can be used to add and remove keys from a file. These flags use\nthe comma separated syntax as the ``--kms``, ``--pgp``, ``--gcp-kms``, ``--hckms`` and ``--azure-kv``\narguments when creating new files.\n\nUse ``updatekeys`` if you want to add a key without rotating the data key.\n\n.. code:: sh\n\n    # add a new pgp key to the file and rotate the data key\n    $ sops rotate -i --add-pgp 85D77543B3D624B63CEA9E6DBC17301B491B3F21 example.yaml\n\n    # remove a pgp key from the file and rotate the data key\n    $ sops rotate -i --rm-pgp 85D77543B3D624B63CEA9E6DBC17301B491B3F21 example.yaml\n\n\nDirect Editing\n**************\n\nAlternatively, invoking ``sops edit`` with the flag **-s** will display the master keys\nwhile editing. This method can be used to add or remove ``kms`` or ``pgp`` keys under the\n``sops`` section.\n\nFor example, to add a KMS master key to a file, add the following entry while\nediting:\n\n.. code:: yaml\n\n    sops:\n        kms:\n            - arn: arn:aws:kms:us-east-1:656532927350:key\u002F920aff2e-c5f1-4040-943a-047fa387b27e\n\nAnd, similarly, to add a PGP master key, we add its fingerprint:\n\n.. code:: yaml\n\n    sops:\n        pgp:\n            - fp: 85D77543B3D624B63CEA9E6DBC17301B491B3F21\n\nWhen the file is saved, SOPS will update its metadata and encrypt the data key\nwith the freshly added master keys. The removed entries are simply deleted from\nthe file.\n\nWhen removing keys, it is recommended to rotate the data key using ``-r``,\notherwise, owners of the removed key may have add access to the data key in the\npast.\n\nKMS AWS Profiles\n~~~~~~~~~~~~~~~~\n\nIf you want to use a specific profile, you can do so with `aws_profile`:\n\n.. code:: yaml\n\n    sops:\n        kms:\n            - arn: arn:aws:kms:us-east-1:656532927350:key\u002F920aff2e-c5f1-4040-943a-047fa387b27e\n              aws_profile: foo\n\nIf no AWS profile is set, default credentials will be used.\n\nSimilarly the `--aws-profile` flag can be set with the command line with any of the KMS commands.\n\n\nAssuming roles and using KMS in various AWS accounts\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS has the ability to use KMS in multiple AWS accounts by assuming roles in\neach account. Being able to assume roles is a nice feature of AWS that allows\nadministrators to establish trust relationships between accounts, typically from\nthe most secure account to the least secure one. In our use-case, we use roles\nto indicate that a user of the Master AWS account is allowed to make use of KMS\nmaster keys in development and staging AWS accounts. Using roles, a single file\ncan be encrypted with KMS keys in multiple accounts, thus increasing reliability\nand ease of use.\n\nYou can use keys in various accounts by tying each KMS master key to a role that\nthe user is allowed to assume in each account. The `IAM roles\n\u003Chttp:\u002F\u002Fdocs.aws.amazon.com\u002FIAM\u002Flatest\u002FUserGuide\u002Fid_roles_use.html>`_\ndocumentation has full details on how this needs to be configured on AWS's side.\n\nFrom the point of view of SOPS, you only need to specify the role a KMS key\nmust assume alongside its ARN, as follows:\n\n.. code:: yaml\n\n    sops:\n        kms:\n            - arn: arn:aws:kms:us-east-1:656532927350:key\u002F920aff2e-c5f1-4040-943a-047fa387b27e\n              role: arn:aws:iam::927034868273:role\u002Fsops-dev-xyz\n\nThe role must have permission to call Encrypt and Decrypt using KMS. An example\npolicy is shown below.\n\n.. code:: json\n\n    {\n      \"Sid\": \"Allow use of the key\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"kms:Encrypt\",\n        \"kms:Decrypt\",\n        \"kms:ReEncrypt*\",\n        \"kms:GenerateDataKey*\",\n        \"kms:DescribeKey\"\n      ],\n      \"Resource\": \"*\",\n      \"Principal\": {\n        \"AWS\": [\n          \"arn:aws:iam::927034868273:role\u002Fsops-dev-xyz\"\n        ]\n      }\n    }\n\nYou can specify a role in the ``--kms`` flag and ``SOPS_KMS_ARN`` variable by\nappending it to the ARN of the master key, separated by a **+** sign::\n\n    \u003CKMS ARN>+\u003CROLE ARN>\n    arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500+arn:aws:iam::927034868273:role\u002Fsops-dev-xyz\n\nAWS KMS Encryption Context\n~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS has the ability to use `AWS KMS key policy and encryption context\n\u003Chttp:\u002F\u002Fdocs.aws.amazon.com\u002Fkms\u002Flatest\u002Fdeveloperguide\u002Fencryption-context.html>`_\nto refine the access control of a given KMS master key.\n\nWhen creating a new file, you can specify the encryption context in the\n``--encryption-context`` flag by comma separated list of key-value pairs:\n\n.. code:: sh\n\n    $ sops edit --encryption-context Environment:production,Role:web-server test.dev.yaml\n\nThe format of the Encrypt Context string is ``\u003CEncryptionContext Key>:\u003CEncryptionContext Value>,\u003CEncryptionContext Key>:\u003CEncryptionContext Value>,...``\n\nThe encryption context will be stored in the file metadata and does\nnot need to be provided at decryption.\n\nEncryption contexts can be used in conjunction with KMS Key Policies to define\nroles that can only access a given context. An example policy is shown below:\n\n.. code:: json\n\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::111122223333:role\u002FRoleForExampleApp\"\n      },\n      \"Action\": \"kms:Decrypt\",\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"kms:EncryptionContext:AppName\": \"ExampleApp\",\n          \"kms:EncryptionContext:FilePath\": \"\u002Fvar\u002Fopt\u002Fsecrets\u002F\"\n        }\n      }\n    }\n\nKey Rotation\n~~~~~~~~~~~~\n\nIt is recommended to renew the data key on a regular basis. ``sops`` supports key\nrotation via the ``rotate`` command. Invoking it on an existing file causes ``sops``\nto reencrypt the file with a new data key, which is then encrypted with the various\nKMS and PGP master keys defined in the file.\n\nAdd the ``-i`` option to write the rotated file back, instead of printing it to\nstdout.\n\n.. code:: sh\n\n    $ sops rotate example.yaml\n\nUsing .sops.yaml conf to select KMS, PGP and age for new files\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIt is often tedious to specify the ``--kms`` ``--gcp-kms`` ``--hckms`` ``--pgp`` and ``--age`` parameters for creation\nof all new files. If your secrets are stored under a specific directory, like a\n``git`` repository, you can create a ``.sops.yaml`` configuration file at the root\ndirectory to define which keys are used for which filename.\n\n.. note::\n\n  The file needs to be named ``.sops.yaml``. Other names (i.e. ``.sops.yml``) won't be automatically\n  discovered by SOPS. You'll need to pass the ``--config .sops.yml`` option for it to be picked up.\n\nLet's take an example:\n\n* file named **something.dev.yaml** should use one set of KMS A, PGP and age\n* file named **something.prod.yaml** should use another set of KMS B, PGP and age\n* other files use a third set of KMS C and PGP\n* all live under **mysecretrepo\u002Fsomething.{dev,prod,gcp}.yaml**\n\nUnder those circumstances, a file placed at **mysecretrepo\u002F.sops.yaml**\ncan manage the three sets of configurations for the three types of files:\n\n.. code:: yaml\n\n    # creation rules are evaluated sequentially, the first match wins\n    creation_rules:\n        # upon creation of a file that matches the pattern *.dev.yaml,\n        # KMS set A as well as PGP and age is used\n        - path_regex: \\.dev\\.yaml$\n          kms: 'arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500,arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n          age: 'age129h70qwx39k7h5x6l9hg566nwm53527zvamre8vep9e3plsm44uqgy8gla'\n\n        # prod files use KMS set B in the PROD IAM, PGP and age\n        - path_regex: \\.prod\\.yaml$\n          kms: 'arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod,arn:aws:kms:eu-central-1:361527076523:key\u002Fcb1fab90-8d17-42a1-a9d8-334968904f94+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n          age: 'age129h70qwx39k7h5x6l9hg566nwm53527zvamre8vep9e3plsm44uqgy8gla'\n          hc_vault_uris: \"http:\u002F\u002Flocalhost:8200\u002Fv1\u002Fsops\u002Fkeys\u002Fthirdkey\"\n\n        # gcp files using GCP KMS\n        - path_regex: \\.gcp\\.yaml$\n          gcp_kms: projects\u002Fmygcproject\u002Flocations\u002Fglobal\u002FkeyRings\u002Fmykeyring\u002FcryptoKeys\u002Fthekey\n\n        # hckms files using HuaweiCloud KMS\n        - path_regex: \\.hckms\\.yaml$\n          hckms: tr-west-1:abc12345-6789-0123-4567-890123456789,tr-west-2:def67890-1234-5678-9012-345678901234\n\n        # Finally, if the rules above have not matched, this one is a\n        # catchall that will encrypt the file using KMS set C as well as PGP\n        # The absence of a path_regex means it will match everything\n        - kms: 'arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500,arn:aws:kms:us-west-2:142069644989:key\u002F846cfb17-373d-49b9-8baf-f36b04512e47,arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n\nWhen creating any file under **mysecretrepo**, whether at the root or under\na subdirectory, SOPS will recursively look for a ``.sops.yaml`` file. If one is\nfound, the filename of the file being created is compared with the filename\nregexes of the configuration file. The first regex that matches is selected,\nand its KMS and PGP keys are used to encrypt the file. It should be noted that\nthe looking up of ``.sops.yaml`` is from the working directory (CWD) instead of\nthe directory of the encrypting file (see `Issue 242 \u003Chttps:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Fissues\u002F242>`_).\n\nThe ``path_regex`` checks the path of the encrypting file relative to the ``.sops.yaml`` config file. Here is another example:\n\n* files located under directory **development** should use one set of KMS A\n* files located under directory **production** should use another set of KMS B\n* other files use a third set of KMS C\n\n.. code:: yaml\n\n    creation_rules:\n        # upon creation of a file under development,\n        # KMS set A is used\n        - path_regex: .*\u002Fdevelopment\u002F.*\n          kms: 'arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500,arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n\n        # prod files use KMS set B in the PROD IAM\n        - path_regex: .*\u002Fproduction\u002F.*\n          kms: 'arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod,arn:aws:kms:eu-central-1:361527076523:key\u002Fcb1fab90-8d17-42a1-a9d8-334968904f94+arn:aws:iam::361527076523:role\u002Fhiera-sops-prod'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n\n        # other files use KMS set C\n        - kms: 'arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500,arn:aws:kms:us-west-2:142069644989:key\u002F846cfb17-373d-49b9-8baf-f36b04512e47,arn:aws:kms:us-west-2:361527076523:key\u002F5052f06a-5d3f-489e-b86c-57201e06f31e'\n          pgp: 'FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4'\n\nCreating a new file with the right keys is now as simple as\n\n.. code:: sh\n\n    $ sops edit \u003Cnewfile>.prod.yaml\n\nNote that the configuration file is ignored when KMS or PGP parameters are\npassed on the SOPS command line or in environment variables.\n\nSpecify a different GPG executable\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS checks for the ``SOPS_GPG_EXEC`` environment variable. If specified,\nit will attempt to use the executable set there instead of the default\nof ``gpg``.\n\nExample: place the following in your ``~\u002F.bashrc``\n\n.. code:: bash\n\n    SOPS_GPG_EXEC = 'your_gpg_client_wrapper'\n\n\nKey groups\n~~~~~~~~~~\n\nBy default, SOPS encrypts the data key for a file with each of the master keys,\nsuch that if any of the master keys is available, the file can be decrypted.\nHowever, it is sometimes desirable to require access to multiple master keys\nin order to decrypt files. This can be achieved with key groups.\n\nWhen using key groups in SOPS, data keys are split into parts such that keys from\nmultiple groups are required to decrypt a file. SOPS uses Shamir's Secret Sharing\nto split the data key such that each key group has a fragment, each key in the\nkey group can decrypt that fragment, and a configurable number of fragments (threshold)\nare needed to decrypt and piece together the complete data key. When decrypting a\nfile using multiple key groups, SOPS goes through key groups in order, and in\neach group, tries to recover the fragment of the data key using a master key from\nthat group. Once the fragment is recovered, SOPS moves on to the next group,\nuntil enough fragments have been recovered to obtain the complete data key.\n\nBy default, the threshold is set to the number of key groups. For example, if\nyou have three key groups configured in your SOPS file and you don't override\nthe default threshold, then one master key from each of the three groups will\nbe required to decrypt the file.\n\nManagement of key groups is done with the ``sops groups`` command.\n\nFor example, you can add a new key group with 3 PGP keys and 3 KMS keys to the\nfile ``my_file.yaml``:\n\n.. code:: sh\n\n    $ sops groups add --file my_file.yaml --pgp fingerprint1 --pgp fingerprint2 --pgp fingerprint3 --kms arn1 --kms arn2 --kms arn3\n\nOr you can delete the 1st group (group number 0, as groups are zero-indexed)\nfrom ``my_file.yaml``:\n\n.. code:: sh\n\n    $ sops groups delete --file my_file.yaml 0\n\nKey groups can also be specified in the ``.sops.yaml`` config file,\nlike so:\n\n.. code:: yaml\n\n    creation_rules:\n        - path_regex: .*keygroups.*\n          key_groups:\n              # First key group\n              - pgp:\n                    - fingerprint1\n                    - fingerprint2\n                kms:\n                    - arn: arn1\n                      role: role1\n                      context:\n                          foo: bar\n                    - arn: arn2\n                      aws_profile: myprofile\n              # Second key group\n              - pgp:\n                    - fingerprint3\n                    - fingerprint4\n                kms:\n                    - arn: arn3\n                    - arn: arn4\n              # Third key group\n              - pgp:\n                    - fingerprint5\n\nGiven this configuration, we can create a new encrypted file like we normally\nwould, and optionally provide the ``--shamir-secret-sharing-threshold`` command line\nflag if we want to override the default threshold. SOPS will then split the data\nkey into three parts (from the number of key groups) and encrypt each fragment with\nthe master keys found in each group.\n\nFor example:\n\n.. code:: sh\n\n    $ sops edit --shamir-secret-sharing-threshold 2 example.json\n\nAlternatively, you can configure the Shamir threshold for each creation rule in the ``.sops.yaml`` config\nwith ``shamir_threshold``:\n\n.. code:: yaml\n\n    creation_rules:\n        - path_regex: .*keygroups.*\n          shamir_threshold: 2\n          key_groups:\n              # First key group\n              - pgp:\n                    - fingerprint1\n                    - fingerprint2\n                kms:\n                    - arn: arn1\n                      role: role1\n                      context:\n                          foo: bar\n                    - arn: arn2\n                      aws_profile: myprofile\n              # Second key group\n              - pgp:\n                    - fingerprint3\n                    - fingerprint4\n                kms:\n                    - arn: arn3\n                    - arn: arn4\n              # Third key group\n              - pgp:\n                    - fingerprint5\n\nAnd then run ``sops edit example.json``.\n\nThe threshold (``shamir_threshold``) is set to 2, so this configuration will require\nmaster keys from two of the three different key groups in order to decrypt the file.\nYou can then decrypt the file the same way as with any other SOPS file:\n\n.. code:: sh\n\n    $ sops decrypt example.json\n\nKey service\n~~~~~~~~~~~\n\nThere are situations where you might want to run SOPS on a machine that\ndoesn't have direct access to encryption keys such as PGP keys. The ``sops`` key\nservice allows you to forward a socket so that SOPS can access encryption\nkeys stored on a remote machine. This is similar to GPG Agent, but more\nportable.\n\nSOPS uses a client-server approach to encrypting and decrypting the data\nkey. By default, SOPS runs a local key service in-process. SOPS uses a key\nservice client to send an encrypt or decrypt request to a key service, which\nthen performs the operation. The requests are sent using gRPC and Protocol\nBuffers. The requests contain an identifier for the key they should perform\nthe operation with, and the plaintext or encrypted data key. The requests do\nnot contain any cryptographic keys, public or private.\n\n**WARNING: the key service connection currently does not use any sort of\nauthentication or encryption. Therefore, it is recommended that you make sure\nthe connection is authenticated and encrypted in some other way, for example\nthrough an SSH tunnel.**\n\nWhenever we try to encrypt or decrypt a data key, SOPS will try to do so first\nwith the local key service (unless it's disabled), and if that fails, it will\ntry all other remote key services until one succeeds.\n\nYou can start a key service server by running ``sops keyservice``.\n\nYou can specify the key services the ``sops`` binary uses with the\n``--keyservice`` option. This flag can be specified more than once, so you can\nuse multiple key services. Alternatively, a single key service can be specified\nby setting the ``SOPS_KEYSERVICE`` environment variable. The local key service\ncan be disabled with ``--enable-local-keyservice=false`` or by setting the\n``SOPS_ENABLE_LOCAL_KEYSERVICE`` environment variable to ``false``.\n\nFor example, to decrypt a file using both the local key service and the key\nservice exposed on the unix socket located in ``\u002Ftmp\u002Fsops.sock``, you can run:\n\n.. code:: sh\n\n    $ sops decrypt --keyservice unix:\u002F\u002F\u002Ftmp\u002Fsops.sock file.yaml\n\nAnd if you only want to use the key service exposed on the unix socket located\nin ``\u002Ftmp\u002Fsops.sock`` and not the local key service, you can run:\n\n.. code:: sh\n\n    $ sops decrypt --enable-local-keyservice=false --keyservice unix:\u002F\u002F\u002Ftmp\u002Fsops.sock file.yaml\n\nAuditing\n~~~~~~~~\n\nSometimes, users want to be able to tell what files were accessed by whom in an\nenvironment they control. For this reason, SOPS can generate audit logs to\nrecord activity on encrypted files. When enabled, SOPS will write a log entry\ninto a pre-configured PostgreSQL database when a file is decrypted. The log\nincludes a timestamp, the username SOPS is running as, and the file that was\ndecrypted.\n\nIn order to enable auditing, you must first create the database and credentials\nusing the schema found in ``audit\u002Fschema.sql``. This schema defines the\ntables that store the audit events and a role named ``sops`` that only has\npermission to add entries to the audit event tables. The default password for\nthe role ``sops`` is ``sops``. You should change this password.\n\nOnce you have created the database, you have to tell SOPS how to connect to it.\nBecause we don't want users of SOPS to be able to control auditing, the audit\nconfiguration file location is not configurable, and must be at\n``\u002Fetc\u002Fsops\u002Faudit.yaml``. This file should have strict permissions such\nthat only the root user can modify it.\n\nFor example, to enable auditing to a PostgreSQL database named ``sops`` running\non localhost, using the user ``sops`` and the password ``sops``,\n``\u002Fetc\u002Fsops\u002Faudit.yaml`` should have the following contents:\n\n.. code:: yaml\n\n    backends:\n        postgres:\n            - connection_string: \"postgres:\u002F\u002Fsops:sops@localhost\u002Fsops?sslmode=verify-full\"\n\n\nYou can find more information on the ``connection_string`` format in the\n`PostgreSQL docs \u003Chttps:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fstatic\u002Flibpq-connect.html#libpq-connstring>`_.\n\nUnder the ``postgres`` map entry in the above YAML is a list, so one can\nprovide more than one backend, and SOPS will log to all of them:\n\n.. code:: yaml\n\n    backends:\n        postgres:\n            - connection_string: \"postgres:\u002F\u002Fsops:sops@localhost\u002Fsops?sslmode=verify-full\"\n            - connection_string: \"postgres:\u002F\u002Fsops:sops@remotehost\u002Fsops?sslmode=verify-full\"\n\nSaving Output to a File\n~~~~~~~~~~~~~~~~~~~~~~~\nBy default SOPS just dumps all the output to the standard output. We can use the\n``--output`` flag followed by a filename to save the output to the file specified.\nBeware using both ``--in-place`` and ``--output`` flags will result in an error.\n\nPassing Secrets to Other Processes\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nIn addition to writing secrets to standard output and to files on disk, SOPS\nhas two commands for passing decrypted secrets to a new process: ``exec-env``\nand ``exec-file``. These commands will place all output into the environment of\na child process and into a temporary file, respectively. For example, if a\nprogram looks for credentials in its environment, ``exec-env`` can be used to\nensure that the decrypted contents are available only to this process and never\nwritten to disk.\n\n.. code:: sh\n\n    # print secrets to stdout to confirm values\n    $ sops decrypt out.json\n    {\n            \"database_password\": \"jf48t9wfw094gf4nhdf023r\",\n            \"AWS_ACCESS_KEY_ID\": \"AKIAIOSFODNN7EXAMPLE\",\n            \"AWS_SECRET_KEY\": \"wJalrXUtnFEMI\u002FK7MDENG\u002FbPxRfiCYEXAMPLEKEY\"\n    }\n\n    # decrypt out.json and run a command\n    # the command prints the environment variable and runs a script that uses it\n    $ sops exec-env out.json 'echo secret: $database_password; .\u002Fdatabase-import'\n    secret: jf48t9wfw094gf4nhdf023r\n\n    # launch a shell with the secrets available in its environment\n    $ sops exec-env out.json 'sh'\n    sh-3.2# echo $database_password\n    jf48t9wfw094gf4nhdf023r\n\n    # the secret is not accessible anywhere else\n    sh-3.2$ exit\n    $ echo your password: $database_password\n    your password:\n\nIf you want process signals to be sent to the command, for example if you are\nrunning ``exec-env`` to launch a server and your server handles SIGTERM, then the\n``--same-process`` flag can be used to instruct ``sops`` to start your command in\nthe same process instead of a child process. This uses the ``execve`` system call\nand is supported on Unix-like systems.\n\nIf the command you want to run only operates on files, you can use ``exec-file``\ninstead. By default, SOPS will use a FIFO to pass the contents of the\ndecrypted file to the new program. Using a FIFO, secrets are only passed in\nmemory which has two benefits: the plaintext secrets never touch the disk, and\nthe child process can only read the secrets once. In contexts where this won't\nwork, eg platforms like Windows where FIFOs unavailable or secret files that need\nto be available to the child process longer term, the ``--no-fifo`` flag can be\nused to instruct SOPS to use a traditional temporary file that will get cleaned\nup once the process is finished executing. ``exec-file`` behaves similar to\n``find(1)`` in that ``{}`` is used as a placeholder in the command which will be\nsubstituted with the temporary file path (whether a FIFO or an actual file).\n\n.. code:: sh\n\n    # operating on the same file as before, but as a file this time\n    $ sops exec-file out.json 'echo your temporary file: {}; cat {}'\n    your temporary file: \u002Ftmp\u002F.sops894650499\u002Ftmp-file\n    {\n            \"database_password\": \"jf48t9wfw094gf4nhdf023r\",\n            \"AWS_ACCESS_KEY_ID\": \"AKIAIOSFODNN7EXAMPLE\",\n            \"AWS_SECRET_KEY\": \"wJalrXUtnFEMI\u002FK7MDENG\u002FbPxRfiCYEXAMPLEKEY\"\n    }\n\n    # launch a shell with a variable TMPFILE pointing to the temporary file\n    $ sops exec-file --no-fifo out.json 'TMPFILE={} sh'\n    sh-3.2$ echo $TMPFILE\n    \u002Ftmp\u002F.sops506055069\u002Ftmp-file291138648\n    sh-3.2$ cat $TMPFILE\n    {\n            \"database_password\": \"jf48t9wfw094gf4nhdf023r\",\n            \"AWS_ACCESS_KEY_ID\": \"AKIAIOSFODNN7EXAMPLE\",\n            \"AWS_SECRET_KEY\": \"wJalrXUtnFEMI\u002FK7MDENG\u002FbPxRfiCYEXAMPLEKEY\"\n    }\n    sh-3.2$ .\u002Fprogram --config $TMPFILE\n    sh-3.2$ exit\n\n    # try to open the temporary file from earlier\n    $ cat \u002Ftmp\u002F.sops506055069\u002Ftmp-file291138648\n    cat: \u002Ftmp\u002F.sops506055069\u002Ftmp-file291138648: No such file or directory\n\nAdditionally, on unix-like platforms, both ``exec-env`` and ``exec-file``\nsupport dropping privileges before executing the new program via the\n``--user \u003Cusername>`` flag. This is particularly useful in cases where the\nencrypted file is only readable by root, but the target program does not\nneed root privileges to function. This flag should be used where possible\nfor added security.\n\nTo overwrite the default file name (``tmp-file``) in ``exec-file`` use the\n``--filename \u003Cfilename>`` parameter.\n\n.. code:: sh\n\n    # the encrypted file can't be read by the current user\n    $ cat out.json\n    cat: out.json: Permission denied\n\n    # execute sops as root, decrypt secrets, then drop privileges\n    $ sudo sops exec-env --user nobody out.json 'sh'\n    sh-3.2$ echo $database_password\n    jf48t9wfw094gf4nhdf023r\n\n    # dropped privileges, still can't load the original file\n    sh-3.2$ id\n    uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody)\n    sh-3.2$ cat out.json\n    cat: out.json: Permission denied\n\nUsing the publish command\n~~~~~~~~~~~~~~~~~~~~~~~~~\n``sops publish $file`` publishes a file to a pre-configured destination (this lives in the SOPS\nconfig file). Additionally, support re-encryption rules that work just like the creation rules.\n\nThis command requires a ``.sops.yaml`` configuration file. Below is an example:\n\n.. code:: yaml\n\n    destination_rules:\n        - s3_bucket: \"sops-secrets\"\n          path_regex: s3\u002F*\n          recreation_rule:\n              pgp: F69E4901EDBAD2D1753F8C67A64535C4163FB307\n        - gcs_bucket: \"sops-secrets\"\n          path_regex: gcs\u002F*\n          recreation_rule:\n              pgp: F69E4901EDBAD2D1753F8C67A64535C4163FB307\n        - vault_path: \"sops\u002F\"\n          vault_kv_mount_name: \"secret\u002F\" # default\n          vault_kv_version: 2 # default\n          path_regex: vault\u002F*\n          omit_extensions: true\n\nThe above configuration will place all files under ``s3\u002F*`` into the S3 bucket ``sops-secrets``,\nall files under ``gcs\u002F*`` into the GCS bucket ``sops-secrets``, and the contents of all files under\n``vault\u002F*`` into Vault's KV store under the path ``secrets\u002Fsops\u002F``. For the files that will be\npublished to S3 and GCS, it will decrypt them and re-encrypt them using the\n``F69E4901EDBAD2D1753F8C67A64535C4163FB307`` pgp key.\n\nYou would deploy a file to S3 with a command like: ``sops publish s3\u002Fapp.yaml``\n\nTo publish all files in selected directory recursively, you need to specify ``--recursive`` flag.\n\nIf you don't want file extension to appear in destination secret path, use ``--omit-extensions``\nflag or ``omit_extensions: true`` in the destination rule in ``.sops.yaml``.\n\nPublishing to Vault\n*******************\n\nThere are a few settings for Vault that you can place in your destination rules. The first\nis ``vault_path``, which is required. The others are optional, and they are\n``vault_address``, ``vault_kv_mount_name``, ``vault_kv_version``.\n\nSOPS uses the official Vault API provided by Hashicorp, which makes use of `environment\nvariables \u003Chttps:\u002F\u002Fwww.vaultproject.io\u002Fdocs\u002Fcommands\u002F#environment-variables>`_ for\nconfiguring the client.\n\n``vault_kv_mount_name`` is used if your Vault KV is mounted somewhere other than ``secret\u002F``.\n``vault_kv_version`` supports ``1`` and ``2``, with ``2`` being the default.\n\nIf the destination secret path already exists in Vault and contains the same data as the source\nfile, it will be skipped.\n\nBelow is an example of publishing to Vault (using token auth with a local dev instance of Vault).\n\n.. code:: sh\n\n    $ export VAULT_TOKEN=...\n    $ export VAULT_ADDR='http:\u002F\u002F127.0.0.1:8200'\n    $ sops decrypt vault\u002Ftest.yaml\n    example_string: bar\n    example_number: 42\n    example_map:\n        key: value\n    $ sops publish vault\u002Ftest.yaml\n    uploading \u002Fhome\u002Fuser\u002Fsops_directory\u002Fvault\u002Ftest.yaml to http:\u002F\u002F127.0.0.1:8200\u002Fv1\u002Fsecret\u002Fdata\u002Fsops\u002Ftest.yaml ? (y\u002Fn): y\n    $ vault kv get secret\u002Fsops\u002Ftest.yaml\n    ====== Metadata ======\n    Key              Value\n    ---              -----\n    created_time     2019-07-11T03:32:17.074792017Z\n    deletion_time    n\u002Fa\n    destroyed        false\n    version          3\n\n    ========= Data =========\n    Key               Value\n    ---               -----\n    example_map       map[key:value]\n    example_number    42\n    example_string    bar\n\n\nImportant information on types\n------------------------------\n\nYAML, JSON, ENV and INI type extensions\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS uses the file extension to decide which encryption method to use on the file\ncontent. ``YAML``, ``JSON``, ``ENV``, and ``INI`` files are treated as trees of data, and key\u002Fvalues are\nextracted from the files to only encrypt the leaf values. The tree structure is also\nused to check the integrity of the file.\n\nTherefore, if a file is encrypted using a specific format, it needs to be decrypted\nin the same format. The easiest way to achieve this is to conserve the original file\nextension after encrypting a file. For example:\n\n.. code:: sh\n\n    $ sops encrypt -i myfile.json\n    $ sops decrypt myfile.json\n\nIf you want to change the extension of the file once encrypted, you need to provide\n``sops`` with the ``--input-type`` flag upon decryption. For example:\n\n.. code:: sh\n\n    $ sops encrypt myfile.json > myfile.json.enc\n\n    $ sops decrypt --input-type json myfile.json.enc\n\nWhen operating on stdin, use the ``--input-type`` and ``--output-type`` flags as follows:\n\n.. code:: sh\n\n    $ cat myfile.json | sops decrypt --input-type json --output-type json\n\nJSON and JSON_binary indentation\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS indents ``JSON`` files by default using one ``tab``. However, you can change\nthis default behaviour to use ``spaces`` by either using the additional ``--indent=2`` CLI option or\nby configuring ``.sops.yaml`` with the code below.\n\nThe special value ``0`` disables indentation, and ``-1`` uses a single tab.\n\n.. code:: yaml\n\n  stores:\n      json:\n          indent: 2\n      json_binary:\n          indent: 2\n\nYAML indentation\n~~~~~~~~~~~~~~~~\n\nSOPS indents ``YAML`` files by default using 4 spaces. However, you can change\nthis default behaviour by either using the additional ``--indent=2`` CLI option or\nby configuring ``.sops.yaml`` with:\n\n.. code:: yaml\n\n  stores:\n      yaml:\n          indent: 2\n\n.. note::\n\n  The YAML emitter used by SOPS only supports values between 2 and 9. If you specify 1,\n  or 10 and larger, the indent will be 2.\n\nYAML anchors\n~~~~~~~~~~~~\n\nSOPS only supports a subset of ``YAML``'s many types. Encrypting YAML files that\ncontain strings, numbers and booleans will work fine, but files that contain anchors\nwill not work, because the anchors redefine the structure of the file at load time.\n\nThis file will not work in SOPS:\n\n.. code:: yaml\n\n    bill-to:  &id001\n        street: |\n            123 Tornado Alley\n            Suite 16\n        city:   East Centerville\n        state:  KS\n\n    ship-to:  *id001\n\nSOPS uses the path to a value as additional data in the AEAD encryption, and thus\ndynamic paths generated by anchors break the authentication step.\n\nJSON and TEXT file types do not support anchors and thus have no such limitation.\n\nYAML Streams\n~~~~~~~~~~~~\n\n``YAML`` supports having more than one \"document\" in a single file, while\nformats like ``JSON`` do not. SOPS is able to handle both. This means the\nfollowing multi-document will be encrypted as expected:\n\n.. code:: yaml-stream\n\n    ---\n    data: foo\n    ---\n    data: bar\n\nNote that the ``sops`` metadata, i.e. the hash, etc, is computed for the physical\nfile rather than each internal \"document\".\n\nTop-level arrays\n~~~~~~~~~~~~~~~~\n``YAML`` and ``JSON`` top-level arrays are not supported, because SOPS\nneeds a top-level ``sops`` key to store its metadata.\n\nThis file will not work in SOPS:\n\n.. code:: yaml\n\n    ---\n      - some\n      - array\n      - elements\n\nBut this one will work because the ``sops`` key can be added at the same level as the\n``data`` key.\n\n.. code:: yaml\n\n    data:\n        - some\n        - array\n        - elements\n\nSimilarly, with ``JSON`` arrays, this document will not work:\n\n.. code:: json\n\n    [\n      \"some\",\n      \"array\",\n      \"elements\"\n    ]\n\n\nBut this one will work just fine:\n\n.. code:: json\n\n    {\n      \"data\": [\n        \"some\",\n        \"array\",\n        \"elements\"\n      ]\n    }\n\n\nExamples\n--------\n\nTake a look into the `examples folder \u003Chttps:\u002F\u002Fgithub.com\u002Fgetsops\u002Fsops\u002Ftree\u002Fmain\u002Fexamples>`_ for detailed use cases of SOPS in a CI environment. The section below describes specific tips for common use cases.\n\nCreating a new file\n~~~~~~~~~~~~~~~~~~~\n\nThe command below creates a new file with a data key encrypted by KMS and PGP.\n\n.. code:: sh\n\n    $ sops edit --kms \"arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500\" --pgp C9CAB0AF1165060DB58D6D6B2653B624D620786D \u002Fpath\u002Fto\u002Fnew\u002Ffile.yaml\n\nEncrypting an existing file\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSimilar to the previous command, we tell SOPS to use one KMS and one PGP key.\nThe path points to an existing cleartext file, so we give ``sops`` the flag ``-e`` to\nencrypt the file, and redirect the output to a destination file.\n\n.. code:: sh\n\n    $ export SOPS_KMS_ARN=\"arn:aws:kms:us-west-2:927034868273:key\u002Ffe86dd69-4132-404c-ab86-4269956b4500\"\n    $ export SOPS_PGP_FP=\"C9CAB0AF1165060DB58D6D6B2653B624D620786D\"\n    $ sops encrypt \u002Fpath\u002Fto\u002Fexisting\u002Ffile.yaml > \u002Fpath\u002Fto\u002Fnew\u002Fencrypted\u002Ffile.yaml\n\nDecrypt the file with ``-d``.\n\n.. code:: sh\n\n    $ sops decrypt \u002Fpath\u002Fto\u002Fnew\u002Fencrypted\u002Ffile.yaml\n\nEncrypt or decrypt a file in place\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nRather than redirecting the output of ``-e`` or ``-d``, ``sops`` can replace the\noriginal file after encrypting or decrypting it.\n\n.. code:: sh\n\n    # file.yaml is in cleartext\n    $ sops encrypt -i \u002Fpath\u002Fto\u002Fexisting\u002Ffile.yaml\n    # file.yaml is now encrypted\n    $ sops decrypt -i \u002Fpath\u002Fto\u002Fexisting\u002Ffile.yaml\n    # file.yaml is back in cleartext\n\nEncrypting binary files\n~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS primary use case is encrypting YAML, JSON, ENV, and INI configuration files, but it\nalso has the ability to manage binary files. When encrypting a binary, SOPS will\nread the data as bytes, encrypt it, store the encrypted base64 under\n``tree['data']`` and write the result as JSON.\n\nNote that the base64 encoding of encrypted data can actually make the encrypted\nfile larger than the cleartext one.\n\nIn-place encryption\u002Fdecryption also works on binary files.\n\n.. code:: sh\n\n    $ dd if=\u002Fdev\u002Furandom of=\u002Ftmp\u002Fsomerandom bs=1024\n    count=512\n    512+0 records in\n    512+0 records out\n    524288 bytes (524 kB) copied, 0.0466158 s, 11.2 MB\u002Fs\n\n    $ sha512sum \u002Ftmp\u002Fsomerandom\n    9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe \u002Ftmp\u002Fsomerandom\n\n    $ sops encrypt -i \u002Ftmp\u002Fsomerandom\n    please wait while a data encryption key is being generated and stored securely\n\n    $ sops decrypt -i \u002Ftmp\u002Fsomerandom\n\n    $ sha512sum \u002Ftmp\u002Fsomerandom\n    9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe \u002Ftmp\u002Fsomerandom\n\nExtract a sub-part of a document tree\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS can extract a specific part of a YAML or JSON document, by provided the\npath in the ``--extract`` command line flag. This is useful to extract specific\nvalues, like keys, without needing an extra parser.\n\n.. code:: sh\n\n    $ sops decrypt --extract '[\"app2\"][\"key\"]' ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml\n    -----BEGIN RSA PRIVATE KEY-----\n    MIIBPAIBAAJBAPTMNIyHuZtpLYc7VsHQtwOkWYobkUblmHWRmbXzlAX6K8tMf3Wf\n    ImcbNkqAKnELzFAPSBeEMhrBN0PyOC9lYlMCAwEAAQJBALXD4sjuBn1E7Y9aGiMz\n    bJEBuZJ4wbhYxomVoQKfaCu+kH80uLFZKoSz85\u002FySauWE8LgZcMLIBoiXNhDKfQL\n    vHECIQD6tCG9NMFWor69kgbX8vK5Y+QL+kRq+9HK6yZ9a+hsLQIhAPn4Ie6HGTjw\n    fHSTXWZpGSan7NwTkIu4U5q2SlLjcZh\u002FAiEA78NYRRBwGwAYNUqzutGBqyXKUl4u\n    Erb0xAEyVV7e8J0CIQC8VBY8f8yg+Y7Kxbw4zDYGyb3KkXL10YorpeuZR4LuQQIg\n    bKGPkMM4w5blyE1tqGN0T7sJwEx+EUOgacRNqM2ljVA=\n    -----END RSA PRIVATE KEY-----\n\nThe tree path syntax uses regular python dictionary syntax, without the\nvariable name. Extract keys by naming them, and array elements by numbering\nthem.\n\n.. code:: sh\n\n    $ sops decrypt --extract '[\"an_array\"][1]' ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml\n    secretuser2\n\nSet a sub-part in a document tree\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSOPS can set a specific part of a YAML or JSON document, by providing\nthe path and value in the ``set`` command. This is useful to set specific\nvalues, like keys, without needing an editor.\n\n.. code:: sh\n\n    $ sops set ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"app2\"][\"key\"]' '\"app2keystringvalue\"'\n\nThe tree path syntax uses regular python dictionary syntax, without the\nvariable name. Set to keys by naming them, and array elements by\nnumbering them.\n\n.. code:: sh\n\n    $ sops set ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"an_array\"][1]' '\"secretuser2\"'\n\nThe value must be formatted as json.\n\n.. code:: sh\n\n    $ sops set ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"an_array\"][1]' '{\"uid1\":null,\"uid2\":1000,\"uid3\":[\"bob\"]}'\n\nYou can also provide the value from a file or stdin:\n\n.. code:: sh\n\n    # Provide the value from a file\n    $ echo '{\"uid1\":null,\"uid2\":1000,\"uid3\":[\"bob\"]}' > \u002Ftmp\u002Fexample-value\n    $ sops set --value-file ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"an_array\"][1]' \u002Ftmp\u002Fexample-value\n\n    # Provide the value from stdin\n    $ echo '{\"uid1\":null,\"uid2\":1000,\"uid3\":[\"bob\"]}' | sops set --value-stdin ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"an_array\"][1]'\n\nUnset a sub-part in a document tree\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSymmetrically, SOPS can unset a specific part of a YAML or JSON document, by providing\nthe path in the ``unset`` command. This is useful to unset specific values, like keys, without\nneeding an editor.\n\n.. code:: sh\n\n    $ sops unset ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"app2\"][\"key\"]'\n\nThe tree path syntax uses regular python dictionary syntax, without the\nvariable name. Set to keys by naming them, and array elements by\nnumbering them.\n\n.. code:: sh\n\n    $ sops unset ~\u002Fgit\u002Fsvc\u002Fsops\u002Fexample.yaml '[\"an_array\"][1]'\n\nShowing diffs in cleartext in git\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nYou most likely want to store encrypted files in a version controlled repository.\nSOPS can be used with git to decrypt files when showing diffs between versions.\nThis is very handy for reviewing changes or visualizing history.\n\nTo configure SOPS to decrypt files during diff, create a ``.gitattributes`` file\nat the root of your repository that contains a filter and a command.\n\n.. code:: text\n\n    *.yaml diff=sopsdiffer\n\nHere we only care about YAML files. ``sopsdiffer`` is an arbitrary name that we map\nto a SOPS command in the git configuration file of the repository.\n\n.. code:: sh\n\n    $ git config diff.sopsdiffer.textconv \"sops decrypt\"\n\n    $ grep -A 1 sopsdiffer .git\u002Fconfig\n    [diff \"sopsdiffer\"]\n   ","SOPS 是一个用于管理和加密敏感信息的工具，支持YAML、JSON、ENV、INI和BINARY等多种文件格式。它通过AWS KMS、GCP KMS、Azure Key Vault等服务实现数据加密与解密，确保了在不同云环境下的安全性和灵活性。此外，SOPS还兼容PGP加密方式，为用户提供更多选择。该工具非常适合需要跨多个平台或云服务商处理敏感信息的企业及开发者使用，在DevOps实践中尤为有用，能够有效提升团队协作过程中的安全性。",2,"2026-06-11 03:00:30","top_language"]