Terraform-provider-aws: Rufen Sie den Fingerabdruck des OIDC-Anbieters ab, der für EKS-Dienstkonten erforderlich ist

Erstellt am 13. Sept. 2019  ·  39Kommentare  ·  Quelle: hashicorp/terraform-provider-aws

Beschreibung

Neue oder betroffene Ressource(n)

Aktuell kann ich folgendes angeben:

resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = []
  url             = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

Es gibt keine Möglichkeit, den Fingerabdruck für diesen OIDC-Anbieter mit terraform abzurufen.

Beachten Sie, dass beim Erstellen desselben OIDC-Anbieters in der Konsole automatisch der Fingerabdruck ausgefüllt wird, der für EKS-Dienstkonten erforderlich ist, um die richtige IAM-Rolle zu übernehmen.

Verweise

Die aktuelle Methode zum Abrufen von Fingerabdrücken ist hier dokumentiert -> https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html#thumbstep2

enhancement serviciam

Hilfreichster Kommentar

Dies funktioniert mit der Terraform-Wolke

#!/bin/bash

THUMBPRINT=$(echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tac | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON


data "external" "thumbprint" {
  program = [format("%s/bin/get_thumbprint.sh", path.module), data.aws_region.current.name]
}

resource "aws_iam_openid_connect_provider" "this" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumbprint.result.thumbprint]
  url             = module.eks.cluster_oidc_issuer_url
}


Alle 39 Kommentare

+1

Ich bin das Beispiel hier durchgegangen:
https://www.terraform.io/docs/providers/aws/r/eks_cluster.html#enabling -iam-roles-for-service-accounts

Dabei ist thumbprint_list eine leere Liste. Alles funktionierte, bis ich versuchte, tatsächlich eine AWS-Operation durchzuführen:

An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

Ich wünschte wirklich, AWS bietet eine einfachere Möglichkeit, den Fingerabdruck des Zertifikats zu erhalten.

Nach einigem Suchen sieht es so aus, als könnte dies unser Problem lösen, wenn es implementiert wird:
https://github.com/terraform-providers/terraform-provider-tls/issues/52

In der Zwischenzeit ist hier ein schneller Hack, um es zu umgehen, nicht ideal, aber getestet funktioniert

echo | openssl s_client -connect oidc.eks.us-west-2.amazonaws.com:443 2>&- | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}'
locals {
  eks-oidc-thumbprint = "$OUTPUT_FROM_ABOVE"
}

resource "aws_iam_openid_connect_provider" "eks-oidc" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [local.eks-oidc-thumbprint]
  url             = "${aws_eks_cluster.cluster.identity.0.oidc.0.issuer}"
}

Es gibt einen automatisierten Weg, den ich von Kubernetes Slack erhalten habe, der eine externe Quelle verwendet:

### External cli kubergrunt
data "external" "thumb" {
  program = ["kubergrunt", "eks", "oidc-thumbprint", "--issuer-url", aws_eks_cluster.cluster.identity.0.oidc.0.issuer]
}
### OIDC config
resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumb.result.thumbprint]
  url             = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

Ich persönlich denke, dass dieses Fingerabdruck-Ding im terraform-provider-aws-repo leben sollte.
SHA1-Fingerabdrücke haben normalerweise die Form von

SHA1 Fingerprint=63:96:61:30:76:16:08:20:97:18:C5:04:5C:FF:B4:85:6F:B5:39:76

Aber aws_iam_openid_connect_provider muss so sein (ja Kleinbuchstaben)


Ich weiß nicht, ob diese spezifische Transformation allgemein genug ist, um im Terraform TLS-Anbieter zu leben.

Für alle, die Kubergrunt nicht installieren möchten, führe ich sowohl @zzh8829 als auch @marcincuber Workaround zusammen, damit terraform automatisch Fingerabdrücke aus einem externen Skript abruft.

daumenabdruck.sh

#!/bin/bash

THUMBPRINT=$(echo | openssl s_client -connect oidc.eks.$1.amazonaws.com:443 2>&- | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON

terraform.tf

data "external" "thumbprint" {
  program = ["thumbprint.sh", data.aws_region.current.name]
}

resource "aws_iam_openid_connect_provider" "this" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumbprint.result.thumbprint]
  url             = "${aws_eks_cluster.this.identity.0.oidc.0.issuer}"
}

@dogzzdogzz danke für deine Lösung! Leider habe ich es ohne Erfolg versucht. Es gibt mir einen falschen Fingerabdruck.

Nach meinem Verständnis des AWS-Tutorials müssen wir nur das letzte Zertifikat zwischen BEGIN CERTIFICATE und END CERTIFICATE extrahieren, das ist das Zertifikat der Stammzertifizierungsstelle.

Dann können wir es openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}' , um den Fingerabdruck zu extrahieren

Ja, das erzeugt einen nicht funktionierenden Fingerabdruck. Hier ist mein schrecklicher Oneliner, um einen funktionierenden Daumenabdruck zu erstellen:
echo | openssl s_client -servername oidc.eks.${REGION}.amazonaws.com -showcerts -connect oidc.eks.${REGION}.amazonaws.com:443 2>&- | tail -r | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tail -r | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}'

Bearbeiten: Dies ist für OSX, für GNU/Linux ersetzen Sie tail -r durch tac

Vielen Dank! Ich habe die beiden Lösungen kombiniert, um eine funktionierende Terraform-Ressource zu erhalten

Die obigen Lösungen funktionieren also nicht für unser Setup, wir verwenden einen https-Proxy und daher wird die CA-Kette nicht korrekt sein, wenn ich das durchgekommen bin. Ich kann durch eine Bastion tunneln, aber übersehe ich hier etwas, dass CA-Root für jede AWS-Region meistens statisch sein wird, nicht wahr? Wäre es nicht praktikabel, die Fingerabdrücke für jede Region in einer TF-Karte zu behalten, bis sich eine bessere Lösung anbietet?

@chiefy Sie brauchen nicht einmal eine Karte - es sieht so aus, als ob die

Das Festlegen von Fingerabdrücken auf ["9E99A48A9960B14926BB7F3B02E22DA2B0AB7280"] sollte ausreichen :)

@willthames danke für die Bestätigung meiner Vernunft.

Für alle, die Probleme mit unterschiedlichen oder inkonsistenten Fingerabdrücken haben, könnte dies helfen ...

~Wenn Sie openssl s_client -servername oidc.eks.${REGION}.amazonaws.com usw. "innerhalb" des Clusters ausführen (von einem Ihrer EKS-Mitarbeiter), erhalten Sie ein Zertifikat wie:~
Wenn Sie openssl s_client -servername oidc.eks.${REGION}.amazonaws.com usw. "innerhalb" des Pods ausführen, erhalten Sie ein Zertifikat wie:

subject=CN = oidc.eks.us-west-2.amazonaws.com
issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

☝️ Dies ist der gewünschte Fingerabdruck.

Wenn Sie jedoch denselben Vorgang von außerhalb des Clusters ausführen, erhalten Sie wahrscheinlich Folgendes wie:

subject=/CN=*.execute-api.us-west-2.amazonaws.com
issuer=/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon

HTH

@dayglojesus ja, es hilft, aber es gibt immer noch ein Problem mit der Automatisierung. Wenn wir einen Befehl innerhalb des Pods ausführen müssen, um den Fingerabdruck zu erhalten, der zur Automatisierung der IAM-Rollenrichtlinien für ServiceAccounts erforderlich ist, ist die Arbeit unmöglich :-/
Trotzdem thx, da es mein Problem löst, warum der vom Skript generierte Fingerabdruck nicht funktioniert hat und ihn auf andere Weise finden musste. Was noch lustiger ist, es gibt mehr als 1 Zertifikat, um genau zu sein 4 und mit dieser Liste habe ich es zum Laufen gebracht.

@Grejeru Ich stimme zu, dies sollte keine harte Anforderung sein, aber gemäß den Kommentaren von map der richtigen Daumen zu erstellen, einen für jede erforderliche Region.

Das Festlegen von Fingerabdrücken auf ["9E99A48A9960B14926BB7F3B02E22DA2B0AB7280"] sollte ausreichen :)

@willthames Nun , dies führt zu einer ständigen Drift, da der Fingerabdruck klein geschrieben werden muss (zumindest meine Erfahrung).
Alle unsere eu-Regionen haben jedoch den gleichen Fingerabdruck. Ich habe das Skript von außerhalb von VPC sowie von Gitlab-Runner in EKS ausprobiert und habe die gleichen Ergebnisse / Fingerabdrücke.

Ich habe meinen vorherigen hässlichen Einzeiler mit den Vorschlägen hier zusammengeführt und dies gemacht (für tf v.0.11.x):

<module_name>/bin/get_thumbprint.sh

#!/bin/bash
set -e 

XR="${1:-eu-west-1}"
XT=`mktemp`
XXT=`mktemp`

function cleanup {
  rm -f ${XT} ${XXT}
}

trap cleanup SIGHUP SIGINT SIGTERM EXIT

THUMBPRINT=$(echo QUIT | openssl s_client -showcerts -connect oidc.eks.${XR}.amazonaws.com:443 2>/dev/null > ${XT}; cat ${XT} | sed -n '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' | tac | awk '/-----BEGIN CERTIFICATE-----/ {exit} 1' > ${XXT} && echo '-----BEGIN CERTIFICATE-----' >> ${XXT} && tac ${XXT} > ${XT}; openssl x509 -in ${XT} -fingerprint -noout | sed -r 's|.*+?=(.*)|\1|g' | sed 's|:||g' | awk '{print tolower($1)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON

<module_name>/data.tf

data "aws_region" "current" {}
data "external" "thumbprint" {
  program = ["${path.module}/bin/get_thumbprint.sh", "${data.aws_region.current.name}"]
}

<module_name>/main.tf

resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["${data.external.thumbprint.result.thumbprint}"]
  url             = "${data.aws_eks_cluster.this.identity.0.oidc.0.issuer}"
}

Es scheint, dass dies für das kube-system aws-node Servicekonto einwandfrei funktioniert. Zumindest so viel kann ich nach zwei Tagen sagen....

@rastakajakwanna ja, du hast völlig recht, ich glaube, ich habe meinen Kommentar geschrieben, nachdem ich festgestellt hatte, dass es funktioniert hat, aber bevor ich die von dir erwähnte Drift erkannt habe.

Aber ich kodiere buchstäblich nur den (Klein-)Wert in eine Variable. Ich sehe nicht den Vorteil, dass terraform ein Skript ausführt, um einen Wert zu generieren, der bisher in allen Regionen konsistent ist, und da es sich um eine Root-CA handelt, wird dies wahrscheinlich ein Jahrzehnt lang bleiben.

Dies funktioniert mit der Terraform-Wolke

#!/bin/bash

THUMBPRINT=$(echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tac | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON


data "external" "thumbprint" {
  program = [format("%s/bin/get_thumbprint.sh", path.module), data.aws_region.current.name]
}

resource "aws_iam_openid_connect_provider" "this" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumbprint.result.thumbprint]
  url             = module.eks.cluster_oidc_issuer_url
}


Sollte dieses Problem als Bug markiert werden? Die Dokumentation des terraform-Anbieters ist irreführend, da ein leeres thumbprint die Verwendung von EKS IAM mit Dienstkonto nicht zulässt.

@jujugrrr Ich denke nicht, dass dies ein Fehler ist. Terraform fehlt einfach eine Möglichkeit, den Fingerabdruck abzurufen. Ich stimme zu, dass die Dokumentation nicht perfekt ist.

@jujugrrr Ich denke nicht, dass dies ein Fehler ist. Terraform fehlt einfach eine Möglichkeit, den Fingerabdruck abzurufen. Ich stimme zu, dass die Dokumentation nicht perfekt ist.

Fair genug 😄 , ich habe es mit AWS angesprochen, aber es ist ein vernünftiges Verhalten, den Fingerabdruck nicht durch die API-Antwort auf ihrer Seite offenzulegen, weshalb die AWS-Konsole ihn wahrscheinlich der Einfachheit halber automatisch auffüllt.

Folgen wir https://github.com/terraform-providers/terraform-provider-aws/pull/10217

Wenn jemand ein @mzupan- Beispiel auf macOS/BSD/others ausführen muss, tac dort standardmäßig nicht verfügbar ist und Sie entweder coreutils installieren oder durch tail -r ersetzen müssen

#/bin/bash

THUMBPRINT=$(echo | \
    openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | \
    tail -r | \
    sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | \
    tail -r | \
    openssl x509 -fingerprint -noout | \
    sed 's/://g' | awk -F= '{print tolower($2)}')

THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"

echo $THUMBPRINT_JSON

Danke @mzupan ❤️

~Wenn Sie openssl s_client -servername oidc.eks.${REGION}.amazonaws.com usw. "innerhalb" des Clusters ausführen (von einem Ihrer EKS-Mitarbeiter), erhalten Sie ein Zertifikat wie:~
Wenn Sie openssl s_client -servername oidc.eks.${REGION}.amazonaws.com usw. "innerhalb" des Pods ausführen, erhalten Sie ein Zertifikat wie:

@dayglojesus @Grejeru Ich glaube, ich habe das Wurzelproblem für verschiedene Zertifikate von verschiedenen Clients gefunden:

Dies hängt von der Implementierung/Version des Befehls openssl . In OpenSSL (seit 1.1?) sendet das connect automatisch ein servername mit der Verbindung (Server Name Indication). Siehe [1]

Andere Implementierungen wie LibreSSL (auf Mac) oder CodeBuild/AmazonLinux 2 (die OpenSSL 1.0.2 ) setzen servername nicht automatisch, also müssen wir es bereitstellen.

Der folgende Befehl sollte unabhängig von OpenSSL-Versionen/Implementierungen funktionieren:

openssl s_client -connect oidc.eks.eu-central-1.amazonaws.com:443 -servername oidc.eks.eu-central-1.amazonaws.com

[1] https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html

@cippaciong

Ich habe eine aktualisierte Version, die auf eine von tf cloud verwendete env var testet

#!/bin/bash



if [[ -z "${ATLAS_WORKSPACE_SLUG}" ]]; then
  APP="tail -r"
else
  APP="tac"
fi

THUMBPRINT=$(echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | ${APP} | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | ${APP} | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON

Wenn das x509-Fingerabdruckverhalten Ihres openssl standardmäßig auf etwas anderes als sha1 eingestellt ist, erhalten Sie möglicherweise ungültige Fingerabdrücke:

Member must satisfy constraint: [Member must have length less than or equal to 40, Member must have length greater than or equal to 40]

Explizit zu sein behebt dies:

#!/bin/sh
# https://github.com/terraform-providers/terraform-provider-aws/issues/10104

THUMBPRINT=$(echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tac | openssl x509 -fingerprint -sha1 -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON

Der Fingerabdruck scheint sogar derselbe zu sein cn-northwest-1

echo | openssl s_client -servername oidc.eks.cn-northwest-1.amazonaws.com.cn -showcerts -connect oidc.eks.cn-northwest-1.amazonaws.com.cn:443 2>&- | tail -r | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tail -r | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}'

Für alle, die Kubergrunt nicht installieren möchten, führe ich sowohl @zzh8829 als auch @marcincuber Workaround zusammen, damit terraform automatisch Fingerabdrücke aus einem externen Skript abruft.

daumenabdruck.sh

#!/bin/bash

THUMBPRINT=$(echo | openssl s_client -connect oidc.eks.$1.amazonaws.com:443 2>&- | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo $THUMBPRINT_JSON

terraform.tf

data "external" "thumbprint" {
  program = ["thumbprint.sh", data.aws_region.current.name]
}

resource "aws_iam_openid_connect_provider" "this" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumbprint.result.thumbprint]
  url             = "${aws_eks_cluster.this.identity.0.oidc.0.issuer}"
}

@mzupan Ich musste diese Antwort ändern, damit sie für mich funktioniert, da ich sie in einem Modul verwende:
program = ["${path.module}/thumbprint.sh", var.aws_region]

@mzupan Ich musste diese Antwort ändern, damit sie für mich funktioniert, da ich sie in einem Modul verwende:
program = ["${path.module}/thumbprint.sh", var.aws_region]

Sie können data "aws_region" "current" {} im Modul verwenden, es nimmt die Region an, in der Ihr Provider arbeitet, müssen dann aws_region nicht an das Modul übergeben.

Sie können einen Fingerabdruck generieren und in Ihrer Thumbprint_list festlegen, indem Sie diesem Link folgen: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

Dies sind alle Fingerabdrücke von CA nach Region:

3ACE16CA6BAE7B16AAE3707096D1DE7D29093AD8
ap-south-1
59ADE3A3A6039BBA092E920FEE413466493F409C
eu-west-3
3FB881BCACBD420928168C739B07EEF47555946B
eu-west-2
7CA6BE9F14E20973CB2C58452DA9B1E2BEB7236B
eu-west-1
CAB073498D7558FEC3B2C414C006ACBA30805431
ap-northeast-2
2EAFC197C15CDEE5426BFD4D27D3321A685F3B78
ap-northeast-1
B715DC079832DA5FC1D4706515BE48BE79A1C871
sa-east-1
CB454452665937052981CA118417B7A162A25F54
ca-central-1
1C8B5245E80A6B7A0E8BF5FFDAB032273D7D5DF1
ap-southeast-1
F719C49FEA86549E159818880E392C1570C953B6
ap-southeast-2
0148872FA02F3A7D6B38AA88FA5397228B28E08B
eu-central-1
9884072430220E6253011B88F940E4F20F53D0CC
us-east-1
598ADECB9A3E6CC70AA53D64BD5EE4704300382A
us-east-2
750B948515281953BC6F3D717A1E1654ECBFA852
us-west-1
89BABC6D46502653516CC0BA38B14A2B7864D161
us-west-2
63966130761608209718C5045CFFB4856FB53976

Sie können Ihre Variable wie folgt definieren:

thumbprint_list = ["3ACE16CA6BAE7B16AAE3707096D1DE7D29093AD8","59ADE3A3A6039BBA092E920FEE413466493F409C","3FB881BCACBD420928168C739B07EEF47555946B","7CA6BE9F14E20973CB2C58452DA9B1E2BEB7236B","CAB073498D7558FEC3B2C414C006ACBA30805431","2EAFC197C15CDEE5426BFD4D27D3321A685F3B78","B715DC079832DA5FC1D4706515BE48BE79A1C871","CB454452665937052981CA118417B7A162A25F54","1C8B5245E80A6B7A0E8BF5FFDAB032273D7D5DF1","F719C49FEA86549E159818880E392C1570C953B6","0148872FA02F3A7D6B38AA88FA5397228B28E08B","9884072430220E6253011B88F940E4F20F53D0CC","598ADECB9A3E6CC70AA53D64BD5EE4704300382A","750B948515281953BC6F3D717A1E1654ECBFA852","89BABC6D46502653516CC0BA38B14A2B7864D161","63966130761608209718C5045CFFB4856FB53976"]

Befehl zum Abrufen des Fingerabdrucks:

echo | openssl s_client -servername oidc.eks.${region_name}.amazonaws.com -connect oidc.eks.${region_name}.amazonaws.com:443 2>&- | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print $2}'

@romaryoricardo Ich habe dies noch nicht getestet, aber ich empfehle @mzupan (oder @cippaciong für @mzupan- Befehlen generiert werden (ich gehe davon aus, dass für jeden Befehl mehrere Zertifikate ausgespuckt werden, aber nur 1 ist verarbeitet, in @mzupan ist der Fall der neueste und in Ihrem Fall der älteste, obwohl ich

echo | openssl s_client -servername oidc.eks.${region_name}.amazonaws.com -connect oidc.eks.${region_name}.amazonaws.com:443 2>&- | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | openssl x509 -fingerprint -noout -text

während es im anderen am 2034 abläuft.
Außerdem habe ich das @willthames vorschlägt), also haben wir uns in meinem Fall entschieden, den Fingerabdruck einfach im Terraform-Modul fest zu

Für diejenigen, die mit schmutzigen Tricks im Shell-Skript nicht zufrieden sind: get_thumbprint.sh (zB: tac zweimal).
Hier ist ein funktionierendes Python-Skript: (getestet mit Python3)

import socket
from OpenSSL import SSL
import certifi
import sys, json

hostname = f'oidc.eks.{sys.argv[1]}.amazonaws.com'
port = 443


context = SSL.Context(method=SSL.TLSv1_METHOD)
context.load_verify_locations(cafile=certifi.where())

conn = SSL.Connection(context, socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM))
conn.settimeout(5)
conn.connect((hostname, port))
conn.setblocking(1)
conn.do_handshake()
conn.set_tlsext_host_name(hostname.encode())

thumbprint = conn.get_peer_cert_chain()[-1].digest("sha1")
obj = {"thumbprint": thumbprint.decode("utf-8").replace(":", "").lower() }
print(json.dumps(obj))
conn.close()

Für alpine Docker-Images reicht es, Folgendes zu installieren:

apk add py3-openssl
pip3 install certifi

Für Python:3 Docker-Image:

pip3 install pyopenssl certifi

https://github.com/terraform-providers/terraform-provider-aws/issues/10104#issuecomment -632309246 wurde früher ein längeres Zertifikat angezeigt, das 2034 abläuft.

Endpunkt: oidc.eks.ap-northeast-1.amazonaws.com

{"thumbprint": "9e99a48a9960b14926bb7f3b02e22da2b0ab7280"}

Ich habe jedoch dasselbe Skript ausgeführt und es zeigt ein kürzeres Zertifikat an, es läuft am September 2020 ab. (Und stimmt mit der Zertifikatsanzeige im Browser überein.)

Endpunkt: oidc.eks.ap-northeast-1.amazonaws.com

{"thumbprint": "b715dc079832da5fc1d4706515be48be79a1c871"}

Zertifikatskette

, CN=oidc.eks.ap-northeast-1.amazonaws.com, B715DC079832DA5FC1D4706515BE48BE79A1C871, 08/09/2020 21:00:00
, CN=Amazon, OU=Server CA 1B, O=Amazon, C=US, 917E732D330F9A12404F73D8BEA36948B929DFFC, 19/10/2025 09:00:00
, CN=Amazon Root CA 1, O=Amazon, C=US, 06B25927C42A721631C1EFD9431E648FA62E1E39, 31/12/2037 10:00:00
, CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US, 9E99A48A9960B14926BB7F3B02E22DA2B0AB7280, 29/06/2034 02:39:16
Starfield Class 2 Certification Authority, OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US, AD7E1C28B064EF8F6003402014C3D0E3370EB58A, 30/06/2034 02:39:16

image

@guitarrapc Dies ist ein korrekter Wert für Ihre Region. B715DC079832DA5FC1D4706515BE48BE79A1C871 . Der Anfangswert gilt für eine andere Region.
Siehe vorherigen Kommentar https://github.com/terraform-providers/terraform-provider-aws/issues/10104#issuecomment -633130751

Ich habe das Gefühl, dass dies ein Problem ist, das jetzt geschlossen werden kann. Es werden zahlreiche Lösungen vorgeschlagen, die Probleme mit dem OIDC-Anbieter lösen.

Oof, ich habe heute gerade einen neuen Cluster erstellt und er hat ein neues Zertifikat für us-west-2 :

$ region_name=us-west-2; echo | openssl s_client -servername oidc.eks.${region_name}.amazonaws.com -connect oidc.eks.${region_name}.amazonaws.com:443 2>&- | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:a2:dc:f6:0e:ff:f7:41:2f:76:c8:3c:e2:71:0d:6f
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Amazon, OU=Server CA 1B, CN=Amazon
        Validity
            Not Before: Jul 10 00:00:00 2020 GMT
            Not After : Aug 10 12:00:00 2021 GMT
$ region_name=us-west-2; echo | openssl s_client -servername oidc.eks.${region_name}.amazonaws.com -connect oidc.eks.${region_name}.amazonaws.com:443 2>&- | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print $2}'

7FF5BDFA36CD78827820278B4DABB5E1E97C1476

@nickatsegment Ich denke, das liegt daran, dass Sie den gleichen Fehler wie ich gemacht haben und das "Blatt" -Serverzertifikat verwenden, das aufgrund seines kurzen Ablaufs aktualisiert wird. Verwenden Sie stattdessen das Zertifikat der Stammzertifizierungsstelle, das 2034 oder ähnlich abläuft.

Wechseln Sie, um die obigen Befehle zu verwenden, die -showcerts in der openssl-Befehlszeile enthalten, um alle Zertifikate in der Kette anzuzeigen Betriebssystem, das Sie ausführen: tac (Linux) oder tail -r OS/X.

Aus einer Reihe von Quellen, aber mit ausdrücklicher Hilfe dieses Artikels https://medium.com/@michael.kandelaars/did -your-eks-iam-service-account-roles-break-today-2ea50c869aee, dieser Thread & of Natürlich Stackoverflow für bash-fu, ich habe dieses Skript, das den Root-Ca-Fingerabdruck erfasst.

Nicht das Schönste, aber Funktion über Form, oder?

#!/usr/bin/env bash

echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | awk '/-----BEGIN/{f="cert."(n++)} f{print>f} /-----END/{f=""}'

certificates=()

for c in cert.*; do
   certificates+=($(openssl x509 <$c -noout -fingerprint))
done
rm cert.* 

thumbprint=$(echo ${certificates[${#certificates[@]}-1]} | sed 's/://g' | awk -F= '{print tolower($2)}')
thumbprint_json="{\"thumbprint\": \"${thumbprint}\"}"
echo $thumbprint_json

./this_script.sh <aws-region-code>

@tyrken ah ja, du hast recht. Danke für den Hinweis.

Wir hoffen,

Mein externes dafür

extern/Daumenabdruck

#!/bin/bash

set -euo pipefail

HOST="oidc.eks.$1.amazonaws.com"

# https://github.com/terraform-providers/terraform-provider-aws/issues/10104

echo | openssl s_client -servername "$HOST" -showcerts -connect "$HOST:443" 2>&- \
  | sed -n '/-----BEGIN CERTIFICATE-----/h;//!H;$!d;x;s/\(.*-----END CERTIFICATE-----\).*/\1/p' \
  | openssl x509 -fingerprint -sha1 -noout \
  | tr '[:upper:]' '[:lower:]' \
  | sed 's/://g; s/.*=\(.*\)/{"thumbprint": "\1"}/'

Verwenden Sie es so:

data "external" "thumbprint" {
  program = [
    "/bin/sh",
    "${path.module}/external/thumbprint",
    data.aws_region.current.name,
  ]
}

resource "aws_iam_openid_connect_provider" "this" {
  url = aws_eks_cluster.this.identity[0]["oidc"][0]["issuer"]
  client_id_list = [
    "sts.amazonaws.com",
  ]
  thumbprint_list = [
    data.external.thumbprint.result.thumbprint,
  ]
}

Für die Region eu-central-1 wird der Fingerabdruck für dieses Zertifikat zurückgegeben:

Issuer: C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
Validity
    Not Before: Sep  2 00:00:00 2009 GMT
    Not After : Jun 28 17:39:16 2034 GMT
Subject: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2

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 diese Ausgabe erneut geöffnet werden sollte, empfehlen wir Ihnen, eine neue Ausgabe zu erstellen, die für zusätzlichen Kontext mit dieser verknüpft ist. Vielen Dank!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen