getsops / getsops/sops

Why do you recommend to specify multiple KMS keys?

Open
#1,027 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
23.1k
Forks
1.1k
Avg merge
1d 11h
Merged PRs (30d)
9

Description

Background

Thank you for developing this great tool! Could you answer why you recommend to use multiple master keys in the IAM console in different regions? When I read the README, I found the following explanations.

If you're using AWS KMS, create one or multiple master keys in the IAM console and export them, comma separated, in the SOPS_KMS_ARN env variable. It is recommended to use at least two master keys in different regions.

The document is added in 2015. So, I assume that we didn't have keys we can use from multiple AWS regions. Now, we have Multi-Region keys in AWS KMS and I feel this is better than specifying multiple keys.

AWS KMS supports multi-Region keys, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions. Each set of related multi-Region keys has the same key material and key ID, so you can encrypt data in one AWS Region and decrypt it in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS.

What I want to achieve

  • Understand the reason why we recommend to specify multiple KMS keys

Related information

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README section that recommends multiple KMS keys and compare its rationale with the linked AWS Multi-Region keys documentation. Determine whether the recommendation still applies to SOPS and whether the README needs clarification; done means documenting a supported, accurate explanation or identifying the unresolved maintainer decision.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, documentation, security
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.