Paperphyte/Anteckningsbok/Ersätta AWS Access Keys med IAM Roles Anywhere: En certifikatbaserad tutorial

Ersätta AWS Access Keys med IAM Roles Anywhere: En certifikatbaserad tutorial

18 jun 20269 min läsningav Jonas OdencrantsSV
Abstrakt illustration där en tonad nyckel till vänster löses upp i tunna förbindelselinjer som leder till ett upplyst certifikat med sigill, sammankopplat med isometriska moln- och serverblock i dämpade teal-, beige- och marinblå toner.

En praktisk genomgång av hur du ersätter långlivade AWS access keys med certifikatbaserad autentisering via IAM Roles Anywhere – från CA-certifikat och klientcertifikat till Terraform-resurser och aws_signing_helper.

Jag arbetade nyligen med en migrering där robot- och serviceanvändare i AWS flyttades bort från långlivade AWS_ACCESS_KEY_ID och AWS_SECRET_ACCESS_KEY och över till roles-anywhere.

Målet var enkelt: ersätta statisk nyckelbaserad åtkomst med certifikatbaserad autentisering.

I stället för att ge en serviceanvändare permanenta AWS-åtkomstnycklar autentiserar workloaden med utfärdade X.509-certifikat. Dessa certifikat signeras av en certifikatutfärdare, och AWS IAM Roles Anywhere använder den betrodda certifikatkedjan för att utfärda temporära AWS-credentials.

I den här guiden går vi igenom hela uppsättningen:

  1. Generera ett certifikat för en certificate authority.
  2. Spara authority certificate bundle i AWS Secrets Manager.
  3. Utfärda klientcertifikat för workloads.
  4. Konfigurera de Terraform-resurser som krävs:
    • IAM Roles Anywhere trust anchor
    • IAM Roles Anywhere profile
    • IAM role
    • S3 access policy
  5. Konfigurera aws_signing_helper så att lokala verktyg kan autentisera mot AWS med certifikat.

På en övergripande nivå ser lösningen ut så här:

  • Ett root- eller authority-certifikat genereras.
  • Authority-certifikatet konfigureras som en trust anchor i AWS IAM Roles Anywhere.
  • Klientcertifikat utfärdas och signeras av authority-certifikatet.
  • En workload använder aws_signing_helper med klientcertifikatet och den privata nyckeln.
  • AWS validerar certifikatkedjan och returnerar temporära credentials för den konfigurerade IAM-rollen.

Det första scriptet skapar authority-certifikatet. Det är beroende av generate-config-template.sh, som bygger OpenSSL-konfigurationen som används när certifikatet genereras.

Scriptet förutsätter också att användaren som kör det redan är autentiserad mot AWS, eftersom det skriver den genererade trust anchor certificate bundle till AWS Secrets Manager.

generate-certificate.sh

#!/bin/bash
#
# generate-certificate.sh
#
# Generates a self-signed X.509v3 CA certificate for use as an IAM Roles
# Anywhere trust anchor,
#
# The CA certificate is x.509 v3, uses an EC key (secp384r1 by default) and a
# SHA-384 signature, with basicConstraints CA:TRUE and keyUsage Digital
# Signature + Certificate Sign + CRL Sign. It builds the OpenSSL config via
# generate-config-template.sh, then creates a private key and certificate.
#
# Usage:
#   ./generate-certificate.sh \
#  --server test-reports.roles-anywhere.internal \

Hjälpscriptet nedan genererar OpenSSL-konfigurationsfilen som används av scriptet för authority-certifikatet.

Det är användbart eftersom certifikatfält, SAN-värde, constraints och key usage-inställningar definieras på ett och samma ställe. Genom att generera konfigurationen dynamiskt blir certifikatgenereringen repeterbar och enklare att anpassa för olika workloads eller miljöer.

generate-config-template.sh

#!/bin/bash
#
# generate-config-template.sh
#
# Generates an OpenSSL config (req) template. Every field rendered into the
# config is configurable from the command line; sensible defaults are applied
# when a flag is omitted.
#
# Usage:
#   ./generate-config-template.sh --server my.host.example [options]
#
# Run with -h/--help for the full list of options.

set -euo pipefail

När authority-certifikatet finns på plats är nästa steg att utfärda klientcertifikat.

Ett klientcertifikat är det certifikat som en workload eller lokal maskin använder när den autentiserar mot AWS via IAM Roles Anywhere. Det viktiga är att klientcertifikatet måste vara signerat av det authority-certifikat som AWS litar på via trust anchor.

Det här scriptet genererar en privat nyckel, skapar en certificate signing request, signerar requesten med authority-certifikatet och skriver det resulterande klientcertifikatet i PEM-format.

issue-client-certificate.sh

#!/bin/bash
#
# issue-client-certificate.sh
#
# Issues an X.509v3 client (end-entity) certificate signed by a CA, for use
# by a workload authenticating to IAM Roles Anywhere.
#
# The client certificate is x.509 v3, uses an EC key (secp384r1 by default)
# and a SHA-384 signature, with basicConstraints CA:FALSE and keyUsage
# Digital Signature. It is signed by the CA produced by generate-certificate.sh
# (the trust anchor).
#
# Usage:
#   ./issue-client-certificate.sh \
#     --ca-cert ./ca/test-reports/test-reports.crt \

När certifikaten har genererats måste authority-certifikatet kopplas till en IAM Roles Anywhere trust anchor.

Trust anchorn talar om för AWS vilken certificate authority som ska vara betrodd. När trust anchorn finns på plats behöver du också en IAM Roles Anywhere profile och en IAM role som workloaden kan anta.

Terraform-koden nedan skapar de AWS-resurser som behövs för en workload som lagrar och hämtar test reports i en S3-bucket.

main.tf

# Trust anchors
resource "aws_rolesanywhere_trust_anchor" "trust_anchor" {
  name    = "${var.bucket_name}-trust_anchor"
  enabled = true
  source {
    source_data {
      x509_certificate_data = data.aws_secretsmanager_secret_version.certificate_secret.secret_string
    }
    source_type = "CERTIFICATE_BUNDLE"
  }
}

resource "aws_rolesanywhere_profile" "profile" {
  name                = "${var.bucket_name}-profile"
  enabled             = true

Data sources nedan hämtar aktuellt AWS-konto, region, certifikatsecret och den S3-bucket som ska användas. De definierar också IAM policy document som används av IAM-rollen.

Policyn tillåter workloaden att skriva, läsa, lista och hantera multipart uploads för objekt i den valda reports-bucketen.

data.tf

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

data "aws_secretsmanager_secret" "certificate_secret" {
  arn = var.certifcate_secret_arn
}

data "aws_secretsmanager_secret_version" "certificate_secret" {
  secret_id = data.aws_secretsmanager_secret.certificate_secret.id
}

data "aws_s3_bucket" "reports" {
  bucket = var.bucket_name
}

Slutligen behöver modulen två input variables:

  • bucket_name: den S3-bucket som används för rapporterna.
  • certifcate_secret_arn: ARN:et för Secrets Manager-secretet som innehåller certificate bundle.

variables.tf

variable "bucket_name" {
  type = string
}

variable "certifcate_secret_arn" {
  type = string
}

Det sista steget är lokal AWS CLI-autentisering.

För att certifikatbaserad autentisering ska fungera från en lokal maskin eller workloadmiljö behöver du installera och konfigurera aws-signing-helper.

Helpern använder:

  • IAM Roles Anywhere trust anchor ARN
  • IAM Roles Anywhere profile ARN
  • IAM role ARN
  • det utfärdade klientcertifikatet
  • den matchande privata nyckeln

När AWS CLI använder den här profilen körs credential process, certifikatflödet valideras via IAM Roles Anywhere och temporära AWS-credentials returneras.

~/.aws/config

[profile iam_anywhere_test_reports]
region=eu-west-1
credential_process = /usr/local/bin/aws_signing_helper credential-process --trust-anchor-arn arn:aws:rolesanywhere:eu-west-1:${ACCOUNT_ID}:trust-anchor/f0e4cb2-5715-47d9-b093-1c5d8e0ae974 --profile-arn arn:aws:rolesanywhere:eu-west-1:${ACCOUNT_ID}:profile/b548ea86-0137-4a04-bfac-f2d98ad88be0 --role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-reports-trust-role --certificate ./clients/test-reports.pem --private-key ./clients/test-reports.key

Med den här konfigurationen på plats är serviceanvändaren inte längre beroende av långlivade AWS access keys. I stället baseras åtkomsten på certifikat, IAM Roles Anywhere och kortlivade AWS-credentials.

Det ger en renare och säkrare lösning för workloads som behöver AWS-åtkomst utanför AWS, samtidigt som behörigheterna fortsatt styrs via IAM-roller och policies.

← Tillbaka till anteckningsboken
Säg hej

Har du ett problem värt att lösa?

Chatta med oss på WhatsApp. Vi svarar inom 48 timmar.