"Error getting data key: 0 successful groups required, got 0" during Atlantis plan

[byakku]

Hi!

During terraform plan I'm getting the following error:

Error: Error getting data key: 0 successful groups required, got 0

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

I tried different terraform versions, no results. Executing this locally works properly, plan only fails only in the container.

Environment:

• Provider: GCP
• Host: GKE
• Atlantis: v0.17.0 + Google SDK + Sops installed on container
• Terraform versions: 0.13.7 and 1.0.5 both tested, same error
• sops provider: 0.6.3

atlantis.tf

data "sops_file" "secrets" {
  source_file = "atlantis_secrets.sops.yaml"
}


resource "helm_release" "atlantis" {
  name             = "atlantis"
  repository       = "https://runatlantis.github.io/helm-charts"
  chart            = "atlantis"
  namespace        = "atlantis"
  create_namespace = true
  version          = "3.14.0"
  wait             = false

  values = [
    file("atlantis_values.yaml")
  ]

[shrinked, github tokens are here]
}

sopsed file, data/tokens redacted, in the file I have GH related secrets

user: ENC[AES256_GCM,data:...,tag:...,type:str]
token: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]
secret: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]
sops:
    kms: []
    gcp_kms:
        - resource_id: projects/.../locations/global/keyRings/.../cryptoKeys/...-key
          created_at: "2021-08-05T15:18:30Z"
          enc: ...

custom values.yaml

environmentRaw: 
  - name: GOOGLE_APPLICATION_CREDENTIALS
    value: /var/secrets/atlantis-gcp-secret/credentials.json
  - name: KUBECONFIG
    value: /home/atlantis/.kube/config
  - name: ATLANTIS_REPO_CONFIG_JSON
    value: |
      {"repos":[{"id":"/.*/","pre_workflow_hooks":[{"run":"gcloud auth activate-service-account [email protected] \\\n  --key-file=/var/secrets/atlantis-gcp-secret/credentials.json"}]}]}

SA Activation was needed in order to have working helm provider at GKE.

Atlantis has Editor permissions in GCP, so it has R/W access to all resources.

Dockerfile:

FROM runatlantis/atlantis:v0.17.0 

RUN apk add python3 wget vim 
# Downloading and installing gcloud package
RUN curl https://dl.google.com/dl/cloudsdk/release/google-cloud-sdk.tar.gz > /tmp/google-cloud-sdk.tar.gz \
  && mkdir -p /usr/local/gcloud \
  && tar -C /usr/local/gcloud -xf /tmp/google-cloud-sdk.tar.gz \
  && /usr/local/gcloud/google-cloud-sdk/install.sh \
  && rm -rf /tmp/google-cloud-sdk.tar.gz \ 
  && curl -L https://github.com/mozilla/sops/releases/download/v3.7.1/sops-v3.7.1.linux > /tmp/sops \
  && mv /tmp/sops /usr/local/bin/sops && chmod +x /usr/local/bin/sops

# Adding the package path to local
ENV PATH $PATH:/usr/local/gcloud/google-cloud-sdk/bin

COPY atlantis/global/kubeconfig /home/atlantis/.kube/config

---

Do you have any idea if it's related to sops or the provider itself, or how I can debug this further?

Logs with DEBUG level didn't show anything really helpful.

Cheers

[carlpett]

Hi @byakku, The (sadly quite unhelpful) error message comes directly from Sops, and basically means that it couldn't find any working keys to decrypt with. In your case, this would most likely be caused by missing permissions, which would indicate that it doesn't run as the SA you expect it to. It's hard to provide any more specific advice, I'm afraid, but hopefully it can point to where to start debugging. It appears somewhat unclear if the environment variable you are using even works with sops: sops/681?

[byakku]

Thanks for you answer, now I at least know where to look for answers. I'll try figuring things out, I'll update this issue once I find something, so future generations will have a solution for this one.

[leandro-caylent]

Do you have any update on this?

I'm facing the same issue, but using KMS. Same versions as well.

[santinoncs]

It was happening to me but was because the service account hadn't the KMS google cloud proper permissions

• Cloud KMS CryptoKey Decrypter

[dhensby]

I experienced this with Azure KV key and the problem was as @carlpett said, permissions on the key to decrypt were missing.

[enchorb]

When testing locally my Terraform code deploys successfully, however through GitHub Actions I am receiving this error as well for a KMS key on GCP.

The service account both on my local machine and that GitHub Actions are impersonating has 'Owner' permissions so wondering why this error is occurring.

[leandro-caylent]

I could resolve the problem, it was an issue with the permissions.

@enchorb I had the same problem, it didn't work with terraform using atlantis (similar to Github Actions). The problem was that the role atlatis were using didn't have the permissions required to decrypt the KMS key.

[enchorb]

@leandro-caylent The account has 'Owner' permissions and for testing sake I also added the 'Cloud KMS CryptoKey Encrypter/Decrypter' permission but still get the same error

[alexsuninsth]

I am having the same issue. A while ago I have encrypted the secret files using sops and then deployed using Atlantis. Yesterday Atlantis failed during the plan stage. The error message suggested that sops can't find the master key because KMS API is disabled. For some reason sops seems to be looking in a wrong project. I used gcloud auth login and have set my default GCP project using gcloud config set project PROJECT_ID. Both Atlantis SA and my user account have Cloud KMS CryptoKey Decrypter but for some reason sops keeps looking in the wrong project.

UPD: my issue was because I have authenticated using gcloud auth login and not gcloud auth application-default login (as per sops --help). Once I authenticated using app default and confirmed that application_default_credentials.json under ~/.config/gcloud references the project where I have the KMS key everything started to work.

[carlpett]

Hi, There appears to be many different configuration issues discussed in this thread, but as far as I can tell, there are not any issues in the provider itself here. I'll close this, please open a new issue if there are problems with the provider!

[dmytrokosiachenko]

i had same problem, fixed it by removing the aws_profile field from the .sops.yaml.

[benjefferies]

i had same problem, fixed it by removing the aws_profile field from the .sops.yaml.

This fixed it for me too but not an ideal solution as we have multiple AWS profiles for different secrets