Practice: Security, identity and access, and compliance for ML platforms

Generated by Claude through GigAI 0.1.11.10 on 2026-10-12.

Main tool: AWS · AWS IAM and IAM Access Analyzer let you practise the whole identity loop of an ML platform (roles for workloads, least-privilege policies, automated policy checks and account-wide guardrails) at no cost from a laptop. · Alternatives: Google Cloud IAM with Workload Identity Federation (permissions bound to a resource hierarchy instead of per-account policies), Microsoft Entra ID with Azure RBAC (role assignments at management group, subscription or resource scope), HashiCorp Vault (cloud-neutral short-lived secrets you run yourself), and in-cluster tools such as Kubernetes RBAC, Kyverno, OPA Gatekeeper and Sigstore cosign (they control and verify what happens inside the cluster but not access to cloud resources).

Every step links into the tool's own documentation; links were checked on 2026-10-12 · version 1

Setup (one time)

1. Create a free-tier AWS account for practice and lock away the root user credentials; IAM and policy validation cost nothing, so no paid service is needed.
Every later step needs an account you can safely break. Using the root user for daily work is the first habit a platform engineer must drop.
Explained in: Security best practices in IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: You can sign in to the account, no root access keys exist, and the root password is stored in a password manager.
2. Enable a passkey or security key as MFA for your own sign-in in the AWS Management Console.
An ML platform account holds data, model weights and credentials to other systems, so a single stolen password must not be enough to get in.
Explained in: Assign a passkey or security key in the AWS Management Console - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The console security credentials page lists your passkey or security key as an assigned MFA device and sign-in prompts for it.
3. Configure human access through federation with an identity provider so the AWS CLI on your laptop uses temporary credentials instead of long-term access keys.
The rest of the path is run from the CLI, and practising with temporary credentials from the start mirrors how a real platform team works.
Explained in: Security best practices in IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: A CLI identity check returns an assumed-role session and no long-term access key is stored in your local AWS configuration.

Steps

1. Read the IAM introduction and sketch the humans and workloads of a small ML platform (data scientists, a training job, an inference service, a CI pipeline) as identities that need access.
You need the vocabulary of principals, authentication and authorization before any policy you write makes sense. The sketch becomes the plan for the rest of the path.
Explained in: What is IAM? - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: You have a one-page diagram that names each identity and the AWS resources it must reach.
2. Create an IAM role for the training workload with a trust policy that names who may assume it, then assume it from the CLI.
Roles and their trust policies are the core object of workload identity on AWS. Assuming one by hand shows exactly what a pod or pipeline does when it gets temporary credentials.
Explained in: IAM roles - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: An identity check from the CLI shows the training role session, and a principal not named in the trust policy is refused.
3. Write an identity-based JSON policy that lets the training role read one dataset prefix and write one model artifact prefix in a practice bucket, and attach it to the role.
Writing Effect, Action, Resource and Condition by hand is the only way to learn how the policy language scopes access. Wildcards are where most platform over-permissioning starts.
Explained in: Policies and permissions in AWS Identity and Access Management - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The training role can read the dataset prefix and write the artifact prefix, and gets access denied on any other prefix.
4. Write a resource-based policy on the model artifact bucket that allows only the training role to write and only the inference role to read, and compare its effect with the identity-based policy.
Model weights are protected on both the identity side and the resource side. Knowing which policy wins in which case prevents accidental cross-team or cross-account exposure.
Explained in: Identity-based policies and resource-based policies - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: You can state which of the two policies allowed or denied each of three test requests and your test calls confirm it.
5. Create a local kind cluster with one namespace and one service account per ML tenant, write a Kubernetes Role and RoleBinding for each, and create one IAM role per tenant service account so the cluster and cloud boundaries match; a managed EKS cluster is paid, so the local cluster stands in and you assume each tenant role by hand.
Kubernetes RBAC limits what a tenant can do inside the cluster and the IAM role limits what its pods can do in AWS. Tenant isolation only holds when the two map one to one with temporary credentials.
Explained in: Security best practices in IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: A table lists each tenant namespace, its service account and its IAM role, and a tenant cannot list resources in another namespace or assume another tenant's role.
6. Configure a permissions boundary and delegate role creation to a tenant admin role so that any role the tenant creates cannot exceed the boundary.
ML teams need to create their own roles for jobs and pipelines without waiting on the platform team. A boundary is how you allow that without handing over the account.
Explained in: Permissions boundaries for IAM entities - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The tenant admin can create a role with the boundary attached and is denied when trying to create one without it.
7. Run IAM Access Analyzer policy validation from the AWS CLI against every policy file you have written so far, kept in a local git repository.
Validation from the CLI is the building block for a CI check that blocks unsafe policies before they are applied. It turns policy review from opinion into a repeatable test.
Explained in: Validate policies with IAM Access Analyzer - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The validation call returns a findings list for each policy file and you have a script that exits with failure when any error or security warning is present.
8. Write a deliberately broken policy with a misspelled action, run validation on it, and fix it using the check reference entry for the finding.
Reading a finding and mapping it to its documented fix is the skill you use when a pipeline check fails on a teammate's pull request.
Explained in: IAM policy validation check reference - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The first run reports an invalid action error and the rerun after your fix reports no findings.
9. Create an AWS KMS key reserved for signing or encrypting model artifacts and container images, and run an IAM Access Analyzer access preview on its key policy before applying it.
SLSA-style supply chain integrity depends on only the build identity being able to use the signing key. An access preview proves who can use the key before the policy goes live.
Explained in: Previewing access with IAM Access Analyzer APIs - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The preview shows no external or unexpected principal with access to the key and only the build role is allowed to use it.
10. Generate a least-privilege policy for the training role from its recorded CloudTrail activity using the AWS CLI, and replace the hand-written policy with the generated one.
Hand-written policies drift wide over time. Generating from real activity is the reproducible way to shrink a role to what the workload actually calls.
Explained in: IAM Access Analyzer policy generation - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: A generated policy listing only the actions the role used is attached to the role and the training test calls still succeed.
11. Query last accessed information for every role in the account and record unused services and roles that can reach model endpoints, training data or secrets as evidence in an AI risk register organized by the NIST AI RMF functions; the unused access analyzer is a paid feature, so last accessed information is the free substitute.
AI risk governance needs observable evidence of who can reach models and data, not just a policy document. A recurring access review is the control that auditors ask to see for model and LLM endpoints.
Explained in: Refine permissions in AWS using last accessed information - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: The risk register has one dated entry per role with its unused permissions, an owner and a removal or acceptance decision.
12. Configure a production-like layout by creating an organization with separate member accounts for development and production ML workloads and applying a service control policy as a guardrail, for example denying actions outside approved Regions; AWS Organizations is free.
Real ML platforms isolate environments by account and set guardrails centrally so that no team role, however misconfigured, can break the outer limits. This ties roles, boundaries and validated policies into one layered design.
Explained in: Security best practices in IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-12
Done when: An administrator role in the member account is denied the action that the service control policy blocks while the same action is still allowed where the guardrail does not apply.

Back to Security, identity and access, and compliance for ML platforms