Πώς να στήσετε το AWS IAM Identity Center (SSO) σε ένα startup

Με δύο λόγια: ενεργοποιείτε το IAM Identity Center στο management account του AWS Organization σας, συνδέετε τον identity provider σας (ή χρησιμοποιείτε το ενσωματωμένο directory), φτιάχνετε λίγα permission sets (Admin, PowerUser, ReadOnly, Billing), αναθέτετε groups σε accounts και γυρίζετε το CLI όλων σε aws configure sso. Μετά σβήνετε τους IAM users. Κρατάτε έναν τεκμηριωμένο δρόμο break-glass για την περίπτωση που χαλάσει το ίδιο το SSO.

Το AWS δεν χρεώνει επιπλέον για το IAM Identity Center, και από τη στιγμή που θα στηθεί, το onboarding και το offboarding ενός engineer γίνεται μια αλλαγή σε ένα directory αντί για κυνήγι σε όλα τα accounts.

Πριν ξεκινήσετε: χρειάζεστε AWS Organizations

Το Identity Center ενεργοποιείται από το management account ενός AWS Organization. Έτσι δημιουργείται ένα organization instance, το μόνο είδος που μπορεί να δίνει πρόσβαση σε πολλά AWS accounts.

Το AWS προσφέρει και account instances για ένα μεμονωμένο ή member account, αλλά σύμφωνα με τη σύγκριση των instance types δεν υποστηρίζουν multi-account permissions ούτε είσοδο σε AWS accounts από το access portal. Για την πρόσβαση της ομάδας σας στο AWS, θέλετε το organization instance.

Αν δεν έχετε ακόμα organization, στήστε το πρώτα, με ξεχωριστά accounts τουλάχιστον για production και για όλα τα υπόλοιπα. Τη δομή που προτείνουμε θα τη βρείτε στο AWS Organizations από την πρώτη μέρα.

Βήμα 1: ενεργοποίηση και επιλογή region

Συνδεθείτε στο management account, ανοίξτε το console του IAM Identity Center στο region όπου θέλετε να ζει και πατήστε Enable. Για εταιρεία που δουλεύει στην ΕΕ, διαλέξτε το ευρωπαϊκό region που ήδη χρησιμοποιείτε, π.χ. eu-central-1 ή eu-west-1, ώστε το identity store να βρίσκεται δίπλα στην υπόλοιπη υποδομή σας.

Δύο ρυθμίσεις που αξίζει να αλλάξετε αμέσως:

• Delegated administrator. Δηλώστε ένα member account (security ή shared-services) ως delegated administrator, ώστε η καθημερινή διαχείριση να γίνεται έξω από το management account. Ο οδηγός του AWS για delegated administration το συστήνει ακριβώς για να έχουν όσο το δυνατόν λιγότεροι άνθρωποι πρόσβαση στο management account. Προσοχή: ο delegated admin δεν μπορεί να αλλάξει permission sets που είναι provisioned στο management account· αυτό μένει εκεί σκόπιμα.
• URL του access portal. Αλλάξτε το subdomain d-xxxxxxxxxx.awsapps.com/start σε κάτι που θα θυμάται η ομάδα, π.χ. το όνομα της εταιρείας.

Βήμα 2: επιλογή identity source

Αν η εταιρεία σας έχει ήδη Google Workspace ή Microsoft Entra ID, χρησιμοποιήστε το ως external identity provider, ώστε όταν κάποιος φεύγει να χάνει αυτόματα και την πρόσβαση στο AWS. Το ενσωματωμένο directory του Identity Center έχει νόημα μόνο αν δεν έχετε κανένα κεντρικό directory.

Ο περιορισμός του Google Workspace πιάνει πολλούς απροετοίμαστους. Ο οδηγός του AWS για Google Workspace γράφει ότι το SCIM sync από τη Google περιορίζεται σε χρήστες και ότι το αυτόματο provisioning groups δεν υποστηρίζεται. Μπορείτε να φτιάξετε τα groups στο Identity Center με το Identity Store API (ή με Terraform, παρακάτω) και να διαχειρίζεστε τα μέλη εκεί, ή να τρέξετε το open-source ssosync του AWS για να αντιγράφει τα Google groups. Για μια ομάδα δέκα ατόμων, τρία-τέσσερα groups στο Terraform είναι συνήθως πιο απλό από ένα ακόμα sync job.

Το Microsoft Entra ID κάνει provisioning και χρήστες και groups μέσω SCIM, οπότε η συμμετοχή σε group στο Entra καθορίζει απευθείας την πρόσβαση στο AWS. Δείτε το tutorial για Entra ID.

Όταν γυρίσετε σε external IdP, το console σάς δείχνει το SCIM endpoint και το access token μία και μοναδική φορά. Περάστε τα στον IdP πριν κλείσετε το παράθυρο, και βάλτε υπενθύμιση στο ημερολόγιο για το rotation του token.

Βήμα 3: groups και permission sets

Ένα permission set είναι ένα template από IAM policies. Όταν το αναθέτετε σε ένα account, το Identity Center δημιουργεί το αντίστοιχο IAM role σε εκείνο το account. Ξεκινήστε με τέσσερα, φτιαγμένα γύρω από το πώς δουλεύει πραγματικά η ομάδα, και αναθέστε τα σε groups, ποτέ σε μεμονωμένα άτομα (με μία εξαίρεση, παρακάτω).

Το session duration έχει default μία ώρα και φτάνει μέχρι τις δώδεκα, σύμφωνα με την τεκμηρίωση για το session duration. Κρατήστε σύντομα τα admin sessions, ώστε ένα ξεχασμένο terminal να μη μένει privileged όλη μέρα.

Το PowerUserAccess επιτρέπει τα πάντα εκτός από διαχείριση IAM και Organizations, καλό default για να χτίζει κανείς σε dev account. Στην production, πιο υγιές είναι read-only by default και αλλαγές μόνο μέσω CI· το deploy pipeline πρέπει να έχει δικό του role μέσω OIDC και όχι το session κάποιου ανθρώπου (δείτε το deploy από GitHub Actions χωρίς access keys).

Καθώς μεγαλώνει η ομάδα, αντικαταστήστε τα γενικά managed policies με custom permission sets, π.χ. ένα «Developer» που στην production μπορεί να διαβάζει logs, να συνδέεται σε ECS tasks και τίποτα άλλο.

Βήμα 4: ανάθεση πρόσβασης σε accounts

Ένα assignment είναι τριάδα: group, permission set, account. Ένας τυπικός πίνακας για startup:

Το management account είναι η εξαίρεση στο «μόνο groups». Το AWS συστήνει να αναθέτετε εκεί χρήστες και όχι groups, γιατί αλλιώς όποιος μπορεί να αλλάξει μέλη groups στον IdP σας ελέγχει ποιος φτάνει στο πιο προνομιούχο account του organization.

Βήμα 5: διαχείριση με Terraform

Τα κλικ στο console είναι εντάξει για την πρώτη δοκιμή, αλλά τα permission sets και τα assignments ανήκουν σε κώδικα, με review όπως κάθε άλλη αλλαγή. Τρέξτε το από το management account ή από το delegated administrator account.

data "aws_ssoadmin_instances" "this" {}

locals {
  instance_arn      = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0]

  permission_sets = {
    AdministratorAccess = { policy = "arn:aws:iam::aws:policy/AdministratorAccess", duration = "PT1H" }
    PowerUserAccess     = { policy = "arn:aws:iam::aws:policy/PowerUserAccess", duration = "PT8H" }
    ReadOnlyAccess      = { policy = "arn:aws:iam::aws:policy/ReadOnlyAccess", duration = "PT8H" }
    Billing             = { policy = "arn:aws:iam::aws:policy/job-function/Billing", duration = "PT4H" }
  }

  # group, permission set, account ID
  assignments = [
    { group = "engineers", set = "PowerUserAccess", account = "111111111111" }, # dev
    { group = "engineers", set = "ReadOnlyAccess", account = "222222222222" },  # prod
    { group = "platform-admins", set = "AdministratorAccess", account = "111111111111" },
    { group = "platform-admins", set = "AdministratorAccess", account = "222222222222" },
  ]
}

resource "aws_ssoadmin_permission_set" "this" {
  for_each         = local.permission_sets
  name             = each.key
  instance_arn     = local.instance_arn
  session_duration = each.value.duration
}

resource "aws_ssoadmin_managed_policy_attachment" "this" {
  for_each           = local.permission_sets
  instance_arn       = local.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.this[each.key].arn
  managed_policy_arn = each.value.policy
}

resource "aws_identitystore_group" "this" {
  for_each          = toset(["engineers", "platform-admins", "finance"])
  identity_store_id = local.identity_store_id
  display_name      = each.key
}

resource "aws_ssoadmin_account_assignment" "this" {
  for_each = { for a in local.assignments : "${a.group}-${a.set}-${a.account}" => a }

  instance_arn       = local.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.this[each.value.set].arn
  principal_type     = "GROUP"
  principal_id       = aws_identitystore_group.this[each.value.group].group_id
  target_type        = "AWS_ACCOUNT"
  target_id          = each.value.account
}

Αν τα groups σας έρχονται από το Entra ID μέσω SCIM, μην τα δημιουργείτε στο Terraform· διαβάστε τα με το data source aws_identitystore_group, ώστε το Terraform και το SCIM να μη μαλώνουν για τα ίδια αντικείμενα. Με Google Workspace ή το ενσωματωμένο directory, το resource παραπάνω είναι η σωστή προσέγγιση. Εμείς το κρατάμε σε δικό του Terraform stack με δικό του state, όπως περιγράφουμε στο πώς οργανώνουμε το Terraform state.

Βήμα 6: το CLI περνάει σε SSO

Κάθε engineer τρέχει μία φορά aws configure sso και μετά aws sso login όποτε λήγει το session. Κανένα access key στον δίσκο.

$ aws configure sso
SSO session name (Recommended): acme
SSO start URL [None]: https://acme.awsapps.com/start
SSO region [None]: eu-central-1
SSO registration scopes [None]: sso:account:access

Το CLI ανοίγει browser, διαλέγετε account και role, και γράφει ένα profile μαζί με ένα κοινό block sso-session στο ~/.aws/config. Προσθέστε κι άλλα profiles με το χέρι ώστε να μοιράζονται το ίδιο session:

[sso-session acme]
sso_start_url = https://acme.awsapps.com/start
sso_region = eu-central-1
sso_registration_scopes = sso:account:access

[profile acme-dev]
sso_session = acme
sso_account_id = 111111111111
sso_role_name = PowerUserAccess
region = eu-central-1

[profile acme-prod]
sso_session = acme
sso_account_id = 222222222222
sso_role_name = ReadOnlyAccess
region = eu-central-1

aws sso login --sso-session acme
aws sts get-caller-identity --profile acme-prod

Από το AWS CLI 2.22.0, το sign-in γίνεται by default με PKCE authorization· σε μηχάνημα χωρίς browser, προσθέστε --use-device-code. Λεπτομέρειες στον οδηγό SSO του AWS CLI. Το Terraform, τα AWS SDKs και τα περισσότερα εργαλεία διαβάζουν απευθείας αυτά τα profiles, οπότε το AWS_PROFILE=acme-dev terraform plan απλώς δουλεύει.

Βήμα 7: κατάργηση IAM users και μόνιμων keys

Το SSO βελτιώνει την ασφάλεια μόνο όταν κλείσει ο παλιός δρόμος. Κάντε το μεθοδικά, account προς account.

1. Βγάλτε credential report σε κάθε account (aws iam generate-credential-report και μετά aws iam get-credential-report) και καταγράψτε κάθε IAM user, password και access key με την ημερομηνία τελευταίας χρήσης.
2. Χωρίστε τους σε ανθρώπους (πάνε σε SSO), CI συστήματα (πάνε σε OIDC roles) και εφαρμογές (πάνε σε instance, task ή pod roles).
3. Απενεργοποιήστε τα keys πριν τα σβήσετε. Περιμένετε μια εβδομάδα, δείτε αν σπάει κάτι, και μετά σβήστε keys και users.
4. Βάλτε guardrail: alert στα events CreateAccessKey και CreateUser στο CloudTrail, ή ένα SCP που τα απαγορεύει εκτός από ένα break-glass role.

Από την εμπειρία μας, οι ουραγοί είναι πάντα οι ίδιοι: ένα third-party εργαλείο που ρυθμίστηκε πριν από χρόνια με admin key, και ένα cron job σε κάποιον server. Βρείτε τα πριν σβήσετε, όχι μετά.

Βήμα 8: σχέδιο για break-glass πρόσβαση

Αν πέσει ο IdP σας ή κάποιος κάνει λάθος ρύθμιση στο Identity Center, χρειάζεστε ακόμα τρόπο να μπείτε. Αποφασίστε τον τώρα, γράψτε τον και δοκιμάστε τον δύο φορές τον χρόνο.

• Root user του management account. Ισχυρό μοναδικό password, hardware MFA keys (καταχωρίστε περισσότερα από ένα), credentials σε χρηματοκιβώτιο ή κοινό vault που θέλει δύο ανθρώπους για να ανοίξει. Alarm σε κάθε root sign-in.
• Root users των member accounts. Με το centralized root access management μπορείτε να σβήσετε εντελώς τα root credentials των member accounts και να κάνετε τις σπάνιες root-only εργασίες με σύντομα privileged sessions από το management account. Τα νέα accounts που δημιουργούνται στο organization δεν έχουν καθόλου root credentials.
• Ένας emergency IAM user ή role (προαιρετικά). Κάποιες ομάδες κρατούν έναν IAM user στο management account, με MFA, credentials σφραγισμένα μαζί με τα root και alert σε κάθε χρήση. Είναι ο μόνος IAM user που αξίζει να έχετε ακόμα.

Γράψτε τη διαδικασία ως σύντομο runbook: ποιος ανοίγει το vault, πώς γίνεται το sign-in, τι διορθώνετε και πώς κάνετε rotate τα credentials μετά. Το template μας για incident response runbook έχει ενότητα ακριβώς γι' αυτό.

Μια σειρά rollout που δουλεύει

1. Ενεργοποίηση Identity Center, δήλωση delegated admin, σύνδεση IdP.
2. Τα τέσσερα permission sets και τα groups στο Terraform.
3. Πρώτα πρόσβαση στο platform team, που για μια εβδομάδα δουλεύει μόνο με SSO.
4. Onboarding των engineers και μετά των οικονομικών.
5. Κατάργηση IAM users και keys, guardrails, δοκιμή break-glass.

Για μικρή ομάδα αυτό είναι θέμα ημερών, όχι εβδομάδων, και είναι από τα πρώτα controls που ελέγχουν οι auditors και οι enterprise πελάτες, είτε στοχεύετε σε SOC 2 είτε σε NIS2. Το identity είναι το πρώτο επίπεδο στα cloud foundations που στήνουμε για τους πελάτες μας· αν προτιμάτε να σχεδιαστεί και να γίνει το rollout από εμάς, μαζί με τη δομή των accounts και την πρόσβαση του CI, είναι μέρος της υπηρεσίας μας για cloud migration και foundations.

Συχνές ερωτήσεις

Ποια η διαφορά ανάμεσα σε AWS SSO και IAM Identity Center;

Είναι η ίδια υπηρεσία. Το AWS μετονόμασε το AWS Single Sign-On σε IAM Identity Center το 2022. Το CLI κρατάει ακόμα το όνομα sso, οπότε εντολές όπως aws configure sso και aws sso login, καθώς και οι ρυθμίσεις sso_ στο ~/.aws/config, αφορούν το IAM Identity Center.

Μπορώ να χρησιμοποιήσω Google Workspace ως identity source στο IAM Identity Center;

Ναι, με SAML για το sign-in και SCIM για το provisioning χρηστών. Το AWS αναφέρει ότι το SCIM sync από το Google Workspace καλύπτει μόνο χρήστες και όχι groups, οπότε τα groups τα φτιάχνετε εσείς στο Identity Center (console, API ή Terraform) ή χρησιμοποιείτε το open-source εργαλείο ssosync.

Πόσο μπορεί να κρατήσει ένα session στο IAM Identity Center;

Κάθε permission set έχει session duration με default μία ώρα, που μπορεί να φτάσει έως δώδεκα ώρες. Κρατήστε σύντομα τα admin permission sets και δώστε μεγαλύτερα sessions μόνο σε ρόλους χαμηλότερου ρίσκου, όπως η read-only πρόσβαση.

Πρέπει να σβήσουμε όλους τους IAM users μετά το IAM Identity Center;

Σβήστε τους IAM users ανθρώπων και CI συστημάτων: οι άνθρωποι πάνε σε SSO και τα pipelines σε OIDC roles. Κρατήστε όμως τεκμηριωμένο δρόμο break-glass: τον root user του management account με hardware MFA και, προαιρετικά, έναν αυστηρά ελεγχόμενο emergency IAM user με alert σε κάθε χρήση.