Terraform-provider-aws: [Funktionsanfrage] Unterstützung für vollständige ACL auf S3-Buckets

Ich vermute, die Syntax wäre so:

resource "aws_s3_bucket" "b" {
  acl {
    acl = "public-read"
    grant_full_control = "[email protected],[email protected]"
    grant_read = "uri=http://acs.amazonaws.com/groups/global/AllUsers"
  }
}

So etwas wäre auch interessant, vielleicht besser geeignet, wenn man die JSON-Aufrufe von AWS sieht, und wahrscheinlich abwärtskompatibeler:

resource "aws_s3_bucket" "b" {
  bucket = "my_tf_test_bucket"
  acl = "private"
  grant {
    display_name = "string"
    email_address = "string"
    id = "int"
    type = "CanonicalUser"|"AmazonCustomerByEmail"|"Group"
    uri  = "string",
    permission = "FULL_CONTROL"|"WRITE"|"WRITE_ACP"|"READ"|"READ_ACP"
  }
  grant {
    ...
  }
}

Wenn ich also das Dokument und die API richtig verstehe, muss für jeden im grant -Parameter angegebenen Empfänger ein BucketInput erstellt werden.

@cjeanneret Ihr Beispiel sieht tatsächlich sehr nach der Access Control Policy aus, die als JSON-Objekt übergeben werden kann:

          {
            "Grants": [
              {
                "Grantee": {
                  "DisplayName": "string",
                  "EmailAddress": "string",
                  "ID": "string",
                  "Type": "CanonicalUser"|"AmazonCustomerByEmail"|"Group",
                  "URI": "string"
                },
                "Permission": "FULL_CONTROL"|"WRITE"|"WRITE_ACP"|"READ"|"READ_ACP"
              }
              ...
            ],
            "Owner": {
              "DisplayName": "string",
              "ID": "string"
            }
          }

Sollen wir es damit umsetzen?

@raphink könnte so noch besser sein, ja. Die Wiederverwendung vorhandener Ressourcen/Daten scheint ziemlich korrekt zu sein.

Das wäre super hilfreich.

Ich habe das tatsächlich vor einiger Zeit implementiert, aber es fehlen Tests:

https://github.com/hashicorp/terraform/pull/13448

Heutzutage habe ich nicht mehr allzu viele Zyklen, aber ich würde das gerne integrieren. Wir verwenden derzeit einen Fork mit diesen Änderungen, da vorgefertigte ACLs für uns nicht ausreichen.

Gibt es hierzu Neuigkeiten? Es wäre wirklich schön, etwas Ähnliches wie den "Policy"-Parameter zu haben. Konservierte ACLs reichen nicht aus, wenn Sie eine komplexe Liste von ACLs haben 👍

@ameir hast du PR-Pläne für deine Implementierung? Wenn nicht, kann ich es übertragen und an Tests arbeiten.

Ich habe die JSON-Version und -Konfiguration über die Variante grant überprüft. Sieht aus wie @cjeanneret Variante der klarste Weg, wenn keine Einwände - ich werde es implementieren.

Sorry für die verspätete Antwort, @Chhed13. Wenn Sie Zyklen haben, um daran zu arbeiten, wäre das großartig. Zur Verdeutlichung habe ich JSON verwendet, weil es mit der Art und Weise übereinstimmte, wie Bucket-Richtlinien in TF verwaltet werden, und weil Sie auch einen einfachen API-Aufruf machen können, um die vollständige ACL herunterzuziehen, um sie einfach zu vergleichen.

Bei der Arbeit habe ich Code geschrieben, um terraform import aller unserer S3-Buckets zu erstellen und HCL aus diesem Zustand zu generieren, und die Dinge in JSON zu haben, hat es einfacher gemacht. Aber so oder so, wir sind besser dran als jetzt (keine erweiterte ACL-Unterstützung). Danke fürs Eingraben!

Hallo! Irgendwelche Gedanken dazu?
Diese Funktion wird besonders beim Erstellen von S3-Buckets für CloudFront-Protokolle benötigt, da CF den Benutzer „awsdatafeeds“ benötigt, um Protokolle mit dieser Einstellung zu schreiben: https://d.pr/i/I8AZMS

Ohne die Möglichkeit zu haben, diese Art von ACL zu kontrollieren, ist es unmöglich, solche Buckets in Terraform zu kontrollieren.

Außerdem – wenn Sie einen vorhandenen Bucket mit dem Benutzer „awsdatafeeds“ in Terraform importieren und dann die ACL-Einstellungen in Terraform ändern, führt $ terraform apply dazu, dass awsdatafeeds gelöscht werden – das kann also ein großer Fehler sein. Außerdem ist diese Änderung in $ terraform plan nicht sichtbar

Beifall!

@Chhed13 , ich bin mir nicht sicher, wo du damit bist. Vielleicht kann ich mir das heute mal anschauen.

Entschuldigung, harte Tage. Ich bin dabei und dabei. PR wird in einem Tag fertig sein.

@orfin @ameir PR ist bereit.
Konservierte ACL- und ACL-Policy-Zuschüsse sind nicht glasklar. Sie enthalten viel Mehrdeutigkeit, denn "was Sie bekommen, ist nicht das, was Sie einstellen".
Canned ACL - kann nur gesetzt werden, und wir sollten damit leben.
Ich überspringe die Option AmazonCustomerByEmail - sie kann auch nur gesetzt werden.
Für DisplayName - braucht es jemand? Ich habe keinen echten Fall dafür gefunden.

Danke, dass du es versucht hast, @Chhed13! Ich habe es noch nicht getestet, aber es sieht gründlich aus.

Vor ein paar Tagen habe ich meine PR aktualisiert und einfach auf https://github.com/terraform-providers/terraform-provider-aws/pull/3757 hochgeladen . Ich bin offen für den Ansatz, den jeder für den besten hält.

Über diesen bin ich auch gerade gestolpert 😞 wäre toll, wenn wir das rausbekommen könnten

Das könnte ich auch gut gebrauchen.

@galdor scheint, dass der beste Weg, dies zu priorisieren, darin besteht, der ursprünglichen PR-Nachricht https://github.com/terraform-providers/terraform-provider-aws/pull/3728#issuecomment -427964123 +1 zu geben

Fertig. Danke schön :)

--
Nikolaus Martjanoff
http://snowsyn.net
[email protected]

Daumen hoch für die PR-Behebung: https://github.com/terraform-providers/terraform-provider-aws/pull/3757

Das scheint so, als wäre die PR bereit zu gehen, was ist hier noch los? Das löscht Dinge, die es nicht sollte, das ist eine große Sache!

Außerdem – wenn Sie einen vorhandenen Bucket mit dem Benutzer „awsdatafeeds“ in Terraform importieren und dann die ACL-Einstellungen in Terraform ändern, bewirkt $ terraform apply, dass awsdatafeeds gelöscht werden – das kann also ein großer Fehler sein. Außerdem ist diese Änderung im $-Terraform-Plan nicht sichtbar

Ich bin heute auch darauf gestoßen, als ich die Protokollierung für CloudFront konfiguriert habe, und würde es gerne zusammenführen.

Das könnte ich auch gut gebrauchen! Was muss passieren, damit diese zusammengeführt werden?

Was hält das auf? Dies ist eine signifikante Auslassung des S3-Bucket-Anbieters und bedeutet, dass ein nicht unerheblicher Prozentsatz der S3-Buckets von Benutzern dem Nicht-Terraform-Management übergeben wird.

Das ist Tod durch tausend Schnitte für eine Lösung. Es gibt wahrscheinlich Hacks, um dies zu umgehen – local-exec oder etwas, das eine Datei über AWS CLI ausgibt – was sofort Code-Gepäck sein wird, wodurch der Infrastruktur-Code für Änderungen spröde wird.

Ich stehe auch vor dem gleichen Problem. Wird das angesprochen? Wie verwendet man Zuschüsse für S3-Bucket-ACLs?

+1 hat heute danach gesucht und ist hier gelandet, was wie etwas in der Nähe aussieht.

Es wäre sehr schön, wenn:

1. Die Dokumente sagten, dass Sie im Moment nur vorgefertigte ACLs ausführen können. Es dauert eine halbe Stunde, um hier zu landen.
2. jemand hat hier ein Beispiel für eine Problemumgehung mit lokalen Befehlen gepostet.

Um mir selbst zu antworten, habe ich hier meine Problemumgehung für s3-Protokollbereitstellungs-ACLs veröffentlicht

Ich warte immer noch auf Feedback von Betreuern zu PR #3728. Daumen hoch - vielleicht hilft das weiter.

Ist dies für zukünftige Versionen geplant?

Ich aktualisiere meine PR nach der Überprüfung. Aber zum gesamten Ablauf kann ich nichts sagen

bin heute auf den Mangel an diesem gestoßen. Dies ist eine hübsche Kernfunktion für S3-Buckets. Ich bin sehr überrascht, dass dies nicht implementiert wurde, seit es vor 2,5 Jahren angesprochen wurde. Kann jemand von Terraform kommentieren, warum dies immer noch fehlt?

@nergdron Das oben verlinkte MR (https://github.com/terraform-providers/terraform-provider-aws/pull/3728) wurde gestern zusammengeführt, sodass es in der nächsten Version enthalten sein wird.

Danke @gdavison , das wird sehr bald sein! 🎉

@tomelliff oh, fantastische Neuigkeiten! Vielen Dank!

Abschließend wurde dies in https://github.com/terraform-providers/terraform-provider-aws/pull/3728 implementiert und wird später oder morgen mit Version 2.52.0 des Terraform AWS Providers veröffentlicht.

Diese wurde in Version 2.52.0 des AWS-Anbieters Terraform freigegeben. Bitte lesen Sie die Terraform-Dokumentation zur Anbieterversionierung oder kontaktieren Sie uns, wenn Sie Hilfe beim Upgrade benötigen.

Für weitere Funktionsanfragen oder Fehlerberichte mit dieser Funktion erstellen Sie bitte ein neues GitHub-Problem gemäß der Vorlage für die Triage. Danke!

Ich bin wahrscheinlich nicht der einzige, der sich fragt, was zum Teufel in Terraform passiert ist, dass alle meine S3-Buckets plötzlich modifiziert werden müssen. Unter diesem Link erfahren Sie, wie Sie zur vordefinierten Standardrichtlinie zurückkehren können. Im Gegensatz zur Dokumentation scheint dies für den grundlegenden Anwendungsfall überhaupt nicht optional zu sein.

Ich werde dieses Problem sperren, da es seit _30 Tagen_ ⏳ geschlossen ist. Dies hilft unseren Betreuern, die aktiven Probleme zu finden und sich darauf zu konzentrieren.

Wenn Sie der Meinung sind, dass dieses Problem erneut geöffnet werden sollte, empfehlen wir Ihnen, ein neues Problem zu erstellen, das für zusätzlichen Kontext auf dieses zurückverlinkt. Danke!