Terraform: Auswählen von Anmeldeinformationen für eine Remote-Statusdatei


10

Ich habe eine vorhandene Infrastruktur in Terraform und benutze sie seit einer Weile. Vor kurzem hatte ich die AWS-Anmeldeinformationen meines lokalen Laptops (die darin gespeicherten Creds ~/.aws/credentials) ausgetauscht und es funktionierte nicht mehr, bis ich diese Anmeldeinformationen zurückgesetzt hatte.

Das Problem ist, dass ich die Creds in der Terraform-Quelle selbst deklariere, aber es scheint, dass sie überhaupt nicht verwendet werden.

terraform {
  backend "s3" {
    bucket = "example_tf_states"
    key    = "global/vpc/us_east_1/example_state.tfstate"
    encrypt = true
    region     = "us-east-1"
  }
}

provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region = "${var.region}"
}



variable "access_key" {
  default = "<hidden_for_stack_exchange_post>"
}

variable "secret_key" {
  default = "<hidden_for_stack_exchange_post>"
}

variable "region" {
  default = "us-east-1"
}

Die Zugriffs-ID-Berechtigungen sind 100% gut. Ich verwende dieselbe Konto-ID und denselben geheimen Schlüssel für die aws configureEinstellungen, die in ~/.aws/credentialsden obigen Terraform-Variablendeklarationen vorgenommen werden.

Alles funktioniert einwandfrei, solange sich die Creds befinden, ~/.aws/credentialsaber sobald die Anmeldeinformationen auf Betriebssystemebene verschwunden sind (dh rm ~/.aws/credentials), wird beim Versuch, Terraform-Vorgänge auszuführen, Folgendes angezeigt terraform plan:

Failed to load backend:
Error configuring the backend "s3": No valid credential sources found for AWS Provider.
  Please see https://terraform.io/docs/providers/aws/index.html for more information on
  providing credentials for the AWS Provider

Please update the configuration in your Terraform files to fix this error.
If you'd like to update the configuration interactively without storing
the values in your configuration, run "terraform init".

Wenn ich das ~/.aws/credentialsdurch Ausführen neu aws configureauffülle, funktioniert es wieder einwandfrei.

Ich verstehe nicht - wenn meine providerEinstellung explizit die Anmeldeinformationen deklariert, die im Terraform-Quellcode verwendet werden sollen, warum ist meine AWS-Konfiguration auf Betriebssystemebene überhaupt wichtig?

Wie kann ich Terraform dazu bringen, nur die in meiner Terraform-Konfiguration definierten Creds zu verwenden und zu ignorieren, was in meinem Betriebssystem-Benutzerprofil enthalten ist?

Bearbeiten, es ist Terraform v0.11.7

Bearbeiten: Bitte beachten Sie, dass ich versuche, das Problem zu lösen, warum die statisch deklarierten Creds in der Anbieterdeklaration nicht verwendet werden. Keine Suche nach alternativen Methoden oder Problemumgehungen. Vielen Dank.


Hrm ... nur eine Ahnung. Stellen Sie sicher , dass AWS_PROFILEoder AWS_DEFAULT_PROFILEUmgebungsvariablen nicht festgelegt , wie sie ein Hinweis auf die AWS SDK sind , dass es in der Credentials - Datei aussehen sollte.
Erik Osterman

Vielen Dank. Späte Antwort, aber ich besuche dies noch einmal. Leider habe ich überprüft, dass die env-Variablen nicht vorhanden sind. Wirklich schön, wenn es zur Laufzeit nach Creds fragen könnte, wie andere Pläne, die kein Remote-Backend verwenden. Trotzdem danke.
Emmee

Antworten:


10

Deine erste Frage

Wenn meine Provider-Einstellung explizit die Anmeldeinformationen deklariert, die im Terraform-Quellcode verwendet werden sollen, warum ist meine AWS-Konfiguration auf Betriebssystemebene überhaupt wichtig?

Die Fehlermeldung "Backend konnte nicht geladen werden: Fehler beim Konfigurieren des Backends" s3 "" bezieht sich auf Ihre Backend S3-Konfiguration.

Schauen Sie in die Datei ./.terraform/terraform.tfstateund Sie werden die S3 Backend Konfiguration sehen.

Das Terraform S3-Backend unterscheidet sich vom Terraform AWS-Anbieter. Die Fehlermeldung "Keine gültigen Anmeldeinformationsquellen für AWS Provider gefunden." ist irreführend. Dies bedeutet, dass die AWS Provider-Konfiguration verwendet wird, was falsch ist. S3-Backend-Anmeldeinformationen werden separat konfiguriert und in der terraform.tfstateDatei gespeichert .

Ihre AWS-Konfiguration auf Betriebssystemebene ist wichtig , da Terraform standardmäßig Folgendes verwendet, wenn keine S3-Backend-Anmeldeinformationen angegeben sind, wie hier unter https://www.terraform.io/docs/backends/types/s3.html dokumentiert.

  1. Umgebungsvariablen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY
  2. AWS Shared Credentials-Datei, Standardwert ist "~ / .aws / credentials".

Sie haben in Ihrer S3-Backend-Konfiguration keine Anmeldeinformationen angegeben, daher verwendet terraform standardmäßig die AWS Shared Credentials-Datei.

Ihre S3-Backend-Konfiguration enthält keine Anmeldeinformationen.

terraform {
  backend "s3" {
    bucket = "example_tf_states"
    key    = "global/vpc/us_east_1/example_state.tfstate"
    encrypt = true
    region     = "us-east-1"
  }
}

Deine zweite Frage,

Wie kann ich Terraform dazu bringen, nur die in meiner Terraform-Konfiguration definierten Creds zu verwenden und zu ignorieren, was in meinem Betriebssystem-Benutzerprofil enthalten ist?

Erstens können Backends keine Interpolation enthalten, siehe https://www.terraform.io/docs/backends/config.html . Sie können also keine Variablen in der Backend-Konfiguration verwenden. zB ist diese Konfiguration ungültig

terraform {
  backend "s3" {
    bucket = "example_tf_states"
    key    = "global/vpc/us_east_1/example_state.tfstate"
    encrypt = true
    region     = "us-east-1"
    access_key = ${var.access_key}
    secret_key = ${var.secret_key}
  }
}

Wenn Sie beim Ausführen AWS-Anmeldeinformationen angeben möchten, geben terraform initSie die Backend-Konfiguration als Optionen an.

terraform init --backend-config="access_key=your_access_key" --backend-config="secret_key=your_secret_key"

Dies erzeugt eine S3-Backend-Konfiguration, die so aussieht und in der ./.terraform/terraform.tfstateDatei gespeichert ist :

{
    "version": 3,
    "serial": 1,
    "lineage": "bd737d2d-1181-ed64-db57-467d14d2155a",
    "backend": {
        "type": "s3",
        "config": {
            "access_key": "your_access_key",
            "secret_key": "your_secret_key"
        },
        "hash": 9345827190033900985
    },

Auch hier werden die S3-Backend-Anmeldeinformationen separat von Ihren AWS Provider-Anmeldeinformationen konfiguriert.

Führen Sie terraform initdie Anmeldeinformationen erneut aus und geben Sie sie in der Befehlszeile als --backend-configOptionen an, um Ihren Fehler zu beheben.


Vielen Dank. Sehr detaillierte Antwort und ich verstehe das Problem jetzt. In meinem Anwendungsfall habe ich letztendlich die shared_credentials_fileOption verwendet, die alle meine Backends und Provider nutzen und nutzen werden. Scheint gut zu funktionieren und nichts ist in den aws-Anmeldeinformationen der OS-Workstation gesperrt.
Emmdee

3

Der Fehler, den Sie erhalten, bezieht sich speziell auf die Konfiguration des S3-Backends, bei dem AFAIK die Einstellungen nicht von der AWS-Anbieterkonfiguration erbt. Es hat auch access_key& secret_keyKonfigurationsoptionen, die Sie ~/.aws/credentialsexplizit konfigurieren müssen, wenn Sie sie nicht verwenden .


1

Sie sind besser dran, Profile in Ihren ~/.aws/credentialsDateien wie einzurichten

[profile1]
aws_access_key_id = xxxx
aws_secret_access_key = xxxxx
region = us-east-1

[profile2]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx
region = us-west-2

Dann können Sie in Ihrem Provider angeben, welches Profil verwendet werden soll

provider "aws" {
  profile = "profile2"
  region = "${var.region}"
}

Dadurch werden die Schlüssel aus Ihren Terraform-Dateien ferngehalten. Dies ist eine gute Sache, wenn Sie sie jemals in die Quellcodeverwaltung übernehmen möchten.


Danke für die Eingabe. Ich bin mir der Anmeldeinformationsprofile sehr bewusst, suche jedoch eher nach einer Lösung für die spezifische Frage als nach einer alternativen Methode oder Problemumgehung. Die Creds müssen sich für den Umfang dieser Frage in Variablen befinden. Trotzdem sehr geschätzt.
Emmdee
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.