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

SOPS with Multi account AWS account #89

Open
gowthamakanthan opened this issue Jul 12, 2022 · 4 comments
Open

SOPS with Multi account AWS account #89

gowthamakanthan opened this issue Jul 12, 2022 · 4 comments

Comments

@gowthamakanthan
Copy link

Team,

We are trying to integrate the SOPS solution with our AWS secret manager using terraform. We have multiple AWS accounts and in one of the accounts, we manage all the secrets(for all of the accounts).

Am trying the following method to push the encrypted secret to the AWS secret manager of the different accounts.

  1. Connected to Account A (using AWS credentials )
  2. Encrypted the secret file using the KMS key ( Used STS from Account B).
   > aws sts assume-role \
     --role-arn <arn> \
     --role-session-name <temp session>
  >  sops -k $aws_kms_dev_arn -e test_secrets_dev.yml > test_secrets_enc_dev.yml
  1. The file is encrypted successfully and able to decrypt using kms arn(with STS)
  2. Have unset the AWS temp sts. and created the following resources to add the encrypted secrets into AWS secret manager.

provider.tf

terraform {
  required_providers {
    sops = {
      source = "carlpett/sops"
      version = "~> 0.5"
    }
  }
}

data file:

data "sops_file" "secrets" {
  source_file = " test_secrets_enc_dev.yml"
}

which is throwing the following error.

Error: Failed to get the data key required to decrypt the SOPS file.

Group 0: FAILED
  <kms arn>: FAILED
    - | Error decrypting key: AccessDeniedException: The ciphertext
      | refers to a customer master key that does not exist, does
      | not exist in this region, or you are not allowed to access.
      | 	status code: 400, request id:
      | 0fc4254a-adc2-4975-ba3d-2de560b82a63

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.

  on secrets.tf line 79, in data "sops_file" "secrets":
  79: data "sops_file" "secrets" {


Releasing state lock. This may take a few moments...

I've tried to add the kms_key_id/ key_id into it, but there is no options to do the same.

data "sops_file" "secrets" {
  source_file = "test_secrets_enc_dev.yml"
  kms_key_id = data.aws_kms_alias.cross_account_kms_alias.id
}

error:


Error: Unsupported argument

  on secrets.tf line 82, in data "sops_file" "secrets":
  82:   kms_key_id = data.aws_kms_alias.cross_account_kms_alias.id

An argument named "kms_key_id" is not expected here.

Is there a way to pass the kms_key_id to decrypt the secret file using data resources?

@cpflaume
Copy link

It would be very nice to be able to switch/assume aws roles like it is possible with the aws provider.
Why? We have a setup in which not all users are able to assume roles. Thus we can not add the role ARN to the SOPS metadata.
Something like this would be nice:

data "sops_file" "secrets" {
  source_file = "test_secrets_enc_dev.yml"
  role_arn = arn:aws:iam::123456789:role/kms-access-role

@kevinneufeld
Copy link

We use the following workaround: We edited the encrypted SOPS file directly, adding a copy of the same KMS block with the role attribute and arn of the role. You can add kms to the group as this data is not part of the [Message Authentication Code](https://github.com/mozilla/sops#id45) calculation.

image

@chickenandpork
Copy link

chickenandpork commented Apr 6, 2023

With some research, there's a way to set this from the command line:

Instead of sops -e --inplace {KMS} {file} such as:

sops -e --in-place \
    --kms "arn:aws:kms:ca-central-1:123456789012:alias/mytestkey" \
    file.yaml

use sops e --inplace {KMS+Role} {file} such as:

sops -e --in-place \
    --kms "arn:aws:kms:ca-central-1:123456789012:alias/mytestkey+arn:aws:iam::123456789012:role/mytestrole" \
    file.yaml

(yup, that's really kms+role)

This seems to set that role value in the SOPS file, and because I had to debug failed role-assumption, it seems to be binding.

qv: https://github.com/mozilla/sops#28assuming-roles-and-using-kms-in-various-aws-accounts

@bryan-rhm
Copy link

you could also modify the .sops.yaml file and add the role you want to assume, however the AWS credentials used while running terraform must have permissions to assume the other role.

creation_rules:

  - path_regex: secrets.enc.yaml
    kms: <KMS_KEY_ARN>+<IAM_ROLE_ARN>

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

No branches or pull requests

5 participants