# IAM roles Published articles for IAM roles. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Best practices for integrating IAM Roles Anywhere with your PKI DevFeed: [Best practices for integrating IAM Roles Anywhere with your PKI]() Original publisher: [Read original article]() Author: Abhishek Avinash Agawane Published: 2026-10-21T17:03:50Z Content type: article Language: en Sources: [AWS Security Blog]() Topics: [AWS IAM](), [Amazon Web Services](), [AWS Security Token Service](), [identity and access management](), [Secrets Management](), [Security](), [enterprise certificate authority certificates](), [Cryptography](), [principle of ephemerality]() Tags: [access-management](), [advanced-300](), [amazon](), [amazon-web-services](), [amazon-web-services-aws](), [aws](), [aws-certificate-manager](), [aws-iam](), [aws-identity-and-access-management-iam](), [best](), [best-practices](), [credentials](), [getting](), [iam](), [iam-roles](), [identity](), [identity-and-access](), [identity-and-access-management](), [pki](), [practices](), [roles](), [security-blog](), [security-identity-compliance](), [with]() ### AI overview IAM Roles Anywhere lets workloads outside AWS exchange CA-signed X.509 certificates for temporary IAM credentials. The article recommends distinct certificates and IAM roles per workload, trust policies that restrict access using certificate-derived subject, issuer or SAN attributes, and session policies to narrow permissions. Trust-anchor placement affects which certificates are accepted; short certificate validity limits exposure, while just-in-time issuance can apply role changes immediately but depends on CA support. Protect private keys with PKCS #11 stores or TPM 2.0 where available; macOS Keychain and Windows certificate stores are also supported. For credentials, SDKs refresh credential_process results in memory, but the AWS CLI invokes it on every command; `serve` avoids that repeated call, while `update` writes credentials to disk and carries file-access risk. The article also recommends expiry monitoring and blue/green trust-anchor rotation. Its sample deployment requires session duration not to exceed the IAM role's MaxSessionDuration and matching configured certificate attributes. ### Source excerpt Using temporary credentials is a security best practice to reduce the risk from credentials getting compromised. With AWS IAM Roles Anywhere, now your workloads outside of Amazon Web Services (AWS) will be able to access AWS resources by obtaining temporary security credentials in AWS Identity and Access Management (IAM). IAM Roles Anywhere relies on public [...] ## Scale your team's use of AWS IAM account access manager with Pulumi DevFeed: [Scale your team's use of AWS IAM account access manager with Pulumi]() Original publisher: [Read original article]() Author: Tatiana Cooke Published: 2026-10-14T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [pulumi](), [AWS IAM](), [Access Control](), [Single sign-on (SSO)](), [Security, Identity, & Compliance](), [CI/CD]() Tags: [administrator](), [aws](), [aws-iam](), [aws-iam-identity-center](), [iam](), [iam-identity-center](), [iam-roles](), [infrastructure-as-code](), [partner](), [product](), [pulumi](), [sdks](), [security]() ### AI overview This tutorial explains how to manage AWS IAM account access manager (AAM) with Pulumi. It covers defining IAM roles, applications, and entitlements as code, scaling group-to-role assignments across AWS accounts, and using policy checks and review workflows. A digital bank is described as adopting AAM to move workforce access to IAM Identity Center while managing roles and entitlements in Pulumi. ### Source excerpt In September 2026, AWS launched AWS IAM account access manager (AAM), which lets administrators assign IAM roles to workforce users and groups in AWS IAM Identity Center. AAM combines IAM Identity Center's single federation point and user awareness with the flexibility of IAM roles. Today, as part of our partner launch enablement, we're pleased to share that you can manage AAM as code with Pulumi. The accountaccess resources ship in the Pulumi AWS provider (v7.45.0 and later) and in the Pulumi AWS Cloud Control provider, AWS Native (v1.75.0 and later), with SDKs generated for every Pulumi language: TypeScript, Python, Go, C#, Java, HCL, and YAML. Teams that already manage their AWS organization with Pulumi can adopt AAM in the same stacks, languages, and review workflows they use today. If you're not using Pulumi today, this post demonstrates how infrastructure as code can help you adopt new AWS services and securely scale them out to your organization faster. In this post, we explain where AAM fits alongside permission sets. We walk through defining roles, applications, and entitlements as code, and we describe how one financial services customer is using this pattern to move its workforce access to IAM Identity Center. The challenge: flexible roles vs. centralized access Until now, organizations managing human access across many AWS accounts have had to choose between two approaches. IAM Identity Center permission sets provide a single sign-on experience and centralized user awareness. IAM Identity Center provisions a permission set into each account as a uniform role. That works well for baseline access, such as read-only or administrator access that looks the same everywhere. But many enterprises need roles that differ from account to account. These roles carry account-specific policies, tags for attribute-based access control (ABAC), custom trust policies, or role paths that encode team and environment. As organizations add accounts, teams, and specialized role ## Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute DevFeed: [Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-09-25T16:01:03Z Content type: article Language: en Sources: [Netflix]() Topics: [App attestation](), [Security, Identity, & Compliance](), [Cloud Architecture](), [amazon]() Tags: [access-control](), [amazon-emr](), [apache-spark](), [attestation](), [audit](), [authentication](), [aws](), [aws-emr](), [certificate](), [cloud](), [compute](), [containers](), [iam](), [iam-roles](), [identity](), [infrastructure](), [job](), [jobs](), [managed](), [mutual-tls](), [netflix](), [security]() ### AI overview Netflix's design gives Spark jobs on Amazon EMR internal identities by corroborating two independent claims: AWS STS reports which IAM role signed a pre-signed identity request, while a signature from the sole authorized control plane describes the dispatched workload. The Data Project service maintains an authoritative one-to-one mapping between each project identity and a dedicated IAM role; roles are deterministically sharded across accounts to support scale. The identity service issues scoped, short-lived certificates only when the AWS-reported role matches the signed metadata. For executors, Netflix chose driver attestation followed by credential distribution over authenticated, AES-GCM-encrypted Spark RPC, avoiding thousands of burst attestation calls at the cost of trusting the driver as a distribution point. The driver periodically re-attests; executors do not renew and can be replaced if credentials expire. ### Source excerpt By Dhruv Pratap Introduction Organizations that have been around for a while usually run two identity systems side by side. One belongs to the cloud provider: IAM roles, instance profiles, execution roles. The other is your own, and it is the one your internal services actually check when they decide whether to answer a request. On infrastructure you build yourself, you can bootstrap your own identity however you like. On managed compute you cannot. The provider hands your process a cloud identity and nothing else. This post describes how we close that gap for Apache Spark workloads running on Amazon EMR. A workload that starts with only an AWS identity has to end up holding a first-class internal identity. Doing the exchange is straightforward. Making it trustworthy is the part that took the design work. Very little of what follows is specific to Spark or to EMR. Two identity systems Internal service-to-service authentication at Netflix runs on a private PKI called Metatron. Every workload gets a short-lived X.509 certificate, and services authenticate each other with mutual TLS. A workload cannot simply ask for a certificate. It is issued only after the identity service has satisfied itself that the requester really is the workload it claims to be. That verification step is called attestation. In each environment we support (VMs, containers, functions) attestation rests on some environment-specific proof that the platform can check on its own. The second concept is the Data Project, which is our unit of ownership for data. A Data Project owns tables, has a set of authorized users, and has an identity of its own. Jobs run as the Data Project rather than as the person who launched them. That is what keeps table-level access control and audit consistent across scheduled and interactive use. So the problem is this. A Spark job on managed compute starts with an AWS execution role and no internal identity. Everything it needs from inside the company (reading an encrypte ## Migrate CloudFormation to Pulumi with Discovered Stacks DevFeed: [Migrate CloudFormation to Pulumi with Discovered Stacks]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [cloud-migration](), [pulumi](), [AWS CloudFormation](), [pulumi-cloud](), [pulumi-neo](), [Amazon VPC](), [Amazon DynamoDB]() Tags: [aws](), [cloudformation](), [database](), [dynamodb](), [iam-roles](), [import](), [insights](), [kinesis](), [kms](), [migration](), [pulumi](), [pulumi-cloud](), [s3](), [secrets](), [tutorials]() ### AI overview Pulumi Discovered Stacks tracks each CloudFormation resource's migration status and treats migration as complete when the code matches the cloud. The excerpt's AWS example has 61 resources: 54 are ready to import, 2 are mapped but not found by Discovery, and 5 have no exact Pulumi type. After scanning the AWS account, users can enable Show Discovered Stacks in Pulumi Cloud and review these statuses in the Migration tab. The tutorial starts migration with Pulumi Neo, but says the same flow can be done with another coding agent or by hand; progress is derived from stack state. The stated quality gate is a zero-diff pulumi preview. The excerpt does not provide the remaining migration steps. ### Source excerpt With Discovered Stacks, Pulumi Cloud does the bookkeeping for a CloudFormation migration: every resource in the stack gets an explicit migration status, and the migration is done when the code provably matches the cloud. In this tutorial, we take one real CloudFormation stack from discovered to migrated and managed by Pulumi IaC, end to end. What we're migrating Our example is payments-api, a CloudFormation stack with 61 resources: a VPC, an Aurora ledger database behind an RDS Proxy, an assets S3 bucket, a DynamoDB ledger table, a Kinesis payment-events pipeline, and the IAM roles, KMS keys, and secrets that wire them together. The plan has five steps: Find the stack in Pulumi Cloud. Review the migration breakdown at a glance. Start the migration. Resolve the stragglers, so every resource is accounted for. Confirm the quality gate: a zero-diff pulumi preview. We'll use Pulumi Neo to do the heavy lifting, but nothing here depends on it. The same flow works with your own coding agent or entirely by hand, because migration status is derived from actual stack state -- however the work gets done, the console shows the same progress. Step 1: Find your stack in Pulumi Cloud Discovered Stacks builds on Discovery, so the only prerequisite is a scanned cloud account -- the AWS account holding your CloudFormation stacks. Once a scan has run, open the Stacks page and turn on Show Discovered Stacks. Your CloudFormation stacks appear alongside your Pulumi stacks. The project name comes from the CloudFormation stack (payments-api), and the stack name encodes the account and region it came from, so the same template deployed to two regions shows up as two distinct discovered stacks. Step 2: Plan the migration at a glance Open the discovered stack's Migration tab. It lays out all 61 resources of payments-api by status, so you can visualize the migration before touching anything: 54 Ready: mapped to a Pulumi type and confirmed to exist -- importable right now. 2 Not found: mapped, but ## Knossos: Procedurally Generated Decoy Environments DevFeed: [Knossos: Procedurally Generated Decoy Environments]() Original publisher: [Read original article]() Author: Praetorian Published: 2026-07-02T17:41:38Z Content type: article Language: en Sources: [Praetorian]() Topics: [cloud-infrastructure](), [Amazon Web Services](), [Amazon VPC](), [Amazon EC2](), [API](), [identity and access management](), [Database](), [function]() Tags: [api](), [attack-path-mapping](), [aws](), [cloud](), [cloud-infrastructure](), [cloud-security](), [iam-roles](), [infrastructure](), [offensive-security](), [praetorian-guard-platform](), [production](), [security-insights]() ### AI overview Praetorian describes Knossos, a procedural engine that learns a customer's real cloud infrastructure and generates realistic AWS decoy environments. These environments can include VPCs, subnets, EC2 instances, databases, Lambda functions, S3 buckets, IAM roles, and secrets, while recording and scoring attacker interactions. ### Source excerpt How we built a procedural engine that learns your real cloud environment, generates decoy environments indistinguishable from production, and converts every attacker interaction into signal. In the myth, Daedalus built the Labyrinth of Knossos so well that he nearly couldn't escape it himself. The corridors looked real. The paths felt purposeful. And the deeper you [...] The post Knossos: Procedurally Generated Decoy Environments appeared first on Praetorian. ## How MCP can help us investigate security incidents faster DevFeed: [How MCP can help us investigate security incidents faster]() Original publisher: [Read original article]() Author: Zichuan Xiong, Paul Rinaldi, Jack Naglieri Published: 2025-07-09T00:00:00Z Content type: article Language: en Sources: [Thoughtworks Insights]() Topics: [Security](), [Model Context Protocol](), [site-reliability-engineering](), [incident](), [Artificial Intelligence](), [VPC Flow Logs]() Tags: [agents](), [ai](), [alert-triage](), [cloud](), [iam](), [iam-roles](), [kubernetes](), [kubernetes-audit-logs](), [logs](), [mcp](), [reliability-engineering](), [security](), [security-incidents]() ### AI overview This article argues that security context should become a core part of AI-assisted site reliability engineering. It describes capabilities for investigating security incidents, including cloud change-history inspection, time-based alert correlation, behavioral detection rules, and contextual analysis of activity logs from sources such as VPC Flow Logs and Kubernetes audit logs. ### Source excerpt How MCP can help us investigate security incidents faster