Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support referencing AWS KMS keys by aliases #415

Merged
merged 3 commits into from
Jan 11, 2019
Merged

Support referencing AWS KMS keys by aliases #415

merged 3 commits into from
Jan 11, 2019

Conversation

darend
Copy link
Contributor

@darend darend commented Jan 10, 2019

what

Allow KMS keys to be referenced by alias instead of the complete ARN

Example use:

creation_rules:
        - kms: "arn:aws:kms:us-west-2:1234567890:alias/my-sops-key,
                arn:aws:kms:us-east-1:1234567890:key/ba2dad9b-032f-42bd-aa69-6dd4012931f4"

why

Addresses issue #381

testing

Unit tests are passing, its not clear how to run the functional tests

@darend
Copy link
Contributor Author

darend commented Jan 10, 2019

cc @snstanton

@codecov-io
Copy link

codecov-io commented Jan 10, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@e398d1c). Click here to learn what that means.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master     #415   +/-   ##
=========================================
  Coverage          ?   43.38%           
=========================================
  Files             ?       16           
  Lines             ?     2206           
  Branches          ?        0           
=========================================
  Hits              ?      957           
  Misses            ?     1160           
  Partials          ?       89
Impacted Files Coverage Δ
kms/keysource.go 50.66% <0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e398d1c...7a78a69. Read the comment docs.

@ajvb ajvb requested a review from autrilla January 10, 2019 23:49
Copy link
Contributor

@autrilla autrilla left a comment

Choose a reason for hiding this comment

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

lgtm. I'm curious why you prefer using aliases vs the full ARN, though. They seem to be about as hard (read: impossible) to memorize as the ARN, since you'd have to memorize the account id, right?

@autrilla autrilla merged commit cfc6fa1 into getsops:master Jan 11, 2019
@darend
Copy link
Contributor Author

darend commented Jan 11, 2019

lgtm. I'm curious why you prefer using aliases vs the full ARN, though. They seem to be about as hard (read: impossible) to memorize as the ARN, since you'd have to memorize the account id, right?

We have multiple environments, each with its own set of keys. When we generate the key we use the environment name as the alias. This makes it very easy to configure sops since our tooling can derive the list of keys.

@autrilla
Copy link
Contributor

I see, good to know!

@Wolfsrudel
Copy link

lgtm. I'm curious why you prefer using aliases vs the full ARN, though. They seem to be about as hard (read: impossible) to memorize as the ARN, since you'd have to memorize the account id, right?

We have multiple environments, each with its own set of keys. When we generate the key we use the environment name as the alias. This makes it very easy to configure sops since our tooling can derive the list of keys.

It's not just that: when the key rotates, the ID changes and you have to adjust the SOPS file. However, with an alias, this change is obsolete as the alias automatically points to the new (rotated) ID.

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.

4 participants