AI agents are inherently unpredictable, so security should focus on the credentials, tools, and enterprise systems they can actually reach rather than trying to enumerate every possible action. The article argues for mapping agent blast radius, reducing local secret exposure, and enforcing controls at the moment credentials are accessed to limit damage from tools like Cursor, MCP, AWS IAM, Microsoft Entra, and Okta. #Cursor #MCP #AWSIAM #MicrosoftEntra #Okta #GitGuardian

https://aws.amazon.com/identity/federation/outbound-federation/ now supports Amazon Virtual Private Cloud (VPC) endpoints for the OpenID Connect (OIDC) discovery APIs. You can now access the OIDC discovery metadata and JSON Web Key Set (JWKS) verification key endpoints from within your VPC using https://aws.amazon.com/privatelink/, without requiring traffic to traverse the public internet. IAM outbound identity federation eliminates the need to use long-lived credentials when your AWS workloads access external services. Instead, your workloads request short-lived JSON Web Tokens (JWTs) from AWS Security Token Service (AWS STS). External services verify these tokens using public verification keys and metadata available at OIDC discovery endpoints. Previously, the OIDC discovery endpoints were only reachable over the public internet, so a verifying workload running in a VPC without internet access could not retrieve them. With this launch, you can create an interface VPC endpoint to reach these endpoints privately, keeping the verification key retrieval traffic within the AWS network. This capability helps you meet network security requirements for workloads that operate in VPCs with restricted internet access, while still enabling external services to verify JWTs. This feature is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and China Regions. There is no additional charge for this feature beyond standard https://aws.amazon.com/privatelink/pricing/. To learn more, see the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sts_oidc_vpc_endpoint_create.html.

AWS Identity and Access Management (IAM) outbound identity federation now supports Amazon Virtual Private Cloud (VPC) endpoints for the OpenID Connect (OIDC) discovery APIs. You can now access the OIDC discovery metadata and JSON Web Key Set (JWKS) verification key endpoints from within your VPC using AWS PrivateLink, without requiring traffic to traverse the public internet. IAM outbound identity federation eliminates the need to use long-lived credentials when your AWS workloads access external services. Instead, your workloads request short-lived JSON Web Tokens (JWTs) from AWS Security Token Service (AWS STS). External services verify these tokens using public verification keys and metadata available at OIDC discovery endpoints. Previously, the OIDC discovery endpoints were only reachable over the public internet, so a verifying workload running in a VPC without internet access could not retrieve them. With this launch, you can create an interface VPC endpoint to reach these endpoints privately, keeping the verification key retrieval traffic within the AWS network. This capability helps you meet network security requirements for workloads that operate in VPCs with restricted internet access, while still enabling external services to verify JWTs. This feature is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and China Regions. There is no additional charge for this feature beyond standard AWS PrivateLink pricing. To learn more, see the IAM User Guide.

Mastering AWS starts with mastering IAM. Understanding users, roles, and permissions builds the security foundation for every AWS service you use. #AWS #AWSIAM #CloudComputing

AWS IAM now enables outbound identity federation, allowing developers to securely authenticate AWS workloads with external services using short-lived JSON Web Tokens instead of storing long-term credentials...

Builders can now sign up for a new simplified experience that makes it faster to turn ideas into running code on AWS. AWS services provide an array of configuration options so that the largest enterprises can customize settings for their distinct needs. Until now, builders with a new project idea had to decide among these options and configure their AWS environment before beginning to build. The new experience reduces setup effort by simplifying sign-up and automatically configuring an initial project with sensible defaults so builders can begin implementing their idea immediately. When you sign up, you can use your existing Google, GitHub, Apple, or Amazon credentials. For most new customers, no credit card is required and you will receive up to $200 in free credits as part of the AWS Free Tier. Once signup is complete, you can connect your coding agent to AWS with a single prompt that automatically installs the AWS CLI and the Agent Toolkit for AWS. Your coding agent connects to your project and uses built-in guidance to deploy resources using best practices. As your project expands, you can invite team members to collaborate with you by email. When a team member accepts your invitation, their project access is configured automatically. Similarly, many of the AWS resources you create can access resources in other AWS services automatically because the new IAM role manager capability is enabled for your projects. When you're ready to upgrade to a paid plan, you can set a monthly spend limit for your project based on your usage patterns so that you stay within your budget. If a project's usage reaches its spend limit, your project is paused for that month. You can create additional projects with one click, each with its own spend limit and distinct team members. At any time, you can activate advanced features without migration or downtime, enabling you to use additional features such as multiple AWS Regions and custom governance controls. To try the new experience, create a new AWS account. To learn more, see AWS reimagines the getting started experience on the AWS News Blog.

Amazon Web Service (AWS) recently announced that AWS Organizations now offers full AWS Identity and Access Management (IAM) policy language support for service control policies (SCPs). With this featu...

Builders can now sign up for a new simplified experience that makes it faster to turn ideas into running code on AWS. AWS services provide an array of configuration options so that the largest enterprises can customize settings for their distinct needs. Until now, builders with a new project idea had to decide among these options and configure their AWS environment before beginning to build. The new experience reduces setup effort by simplifying sign-up and automatically configuring an initial project with sensible defaults so builders can begin implementing their idea immediately. When you sign up, you can use your existing Google, GitHub, Apple, or Amazon credentials. For most new customers, no credit card is required and you will receive up to $200 in free credits as part of the https://aws.amazon.com/free/. Once signup is complete, you can connect your coding agent to AWS with a single prompt that automatically installs the AWS CLI and the https://aws.amazon.com/products/developer-tools/agent-toolkit-for-aws/. Your coding agent connects to your project and uses built-in guidance to deploy resources using best practices. As your project expands, you can invite team members to collaborate with you by email. When a team member accepts your invitation, their project access is configured automatically. Similarly, many of the AWS resources you create can access resources in other AWS services automatically because the new https://aws.amazon.com/blogs/security/how-aws-iam-role-manager-rethinks-the-starting-point-for-iam-roles/ capability is enabled for your projects. When you're ready to upgrade to a paid plan, you can set a monthly spend limit for your project based on your usage patterns so that you stay within your budget. If a project's usage reaches its spend limit, your project is paused for that month. You can create additional projects with one click, each with its own spend limit and distinct team members. At any time, you can activate advanced features without migration or downtime, enabling you to use additional features such as multiple AWS Regions and custom governance controls. To try the new experience, https://signin.aws.amazon.com/signup?request_type=builderId. To learn more, see http://aws.amazon.com/blogs/aws/aws-reimagines-the-getting-started-experience on the AWS News Blog.

Cómo migrar un pipeline completo de GitLab CI a AWS CodeBuild: costos reales, buildspec.yml, ECR mirrors y errores que te van a ahorrar horas de debug.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.htmlhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html (IAM DB Auth) now provides enhanced observability through metrics and logs. It enables customers to investigate and resolve authentication issues when connecting to RDS databases. Database connection authentication issues can occur due to multiple reasons such as configuration or permission issues with your IAM policy, using expired tokens, throttling, etc. IAM DB Auth metrics and logs can help troubleshoot authentication issues caused due to all the above issues. Now you will also get visibility into error logs that help you get insights into user specific connection failures. IAM DB Auth metrics are available in Amazon CloudWatch automatically as long as IAM DB Authentication is enabled on your database instance or cluster. IAM DB Auth error logs can be exported to your CloudWatch Logs account via the https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html feature. Amazon RDS IAM DB Auth metrics and logs are supported by RDS for MySQL, RDS for MariaDB, RDS for PostgreSQL, Aurora MySQL-Compatible Edition, and Aurora PostgreSQL-Compatible Edition. To get started with enabling Amazon RDS IAM DB Authentication, visit: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html and https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html. For troubleshooting Amazon RDS database authentication issues using Amazon RDS IAM DB Auth metrics and logs visit http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html and http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html. To learn more about AWS Identity and Access Management, refer the https://aws.amazon.com/iam/.

AWS Sign-in now supports resource-based policies and resource control policies (RCPs) for the AWS Management Console. You can use these policies to restrict console sign-in to expected networks. Policies are evaluated during sign-in and whenever the console session requests new credentials. Resource-based policies apply to individual AWS accounts. Resource control policies apply organization-wide through AWS Organizations. You can combine these policies with https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html to control both which networks users can sign in from and which accounts they can access. AWS Sign-in resource-based policies and RCPs are available at no additional cost in all AWS commercial Regions. To learn more, see the https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html. For API details, see the https://docs.aws.amazon.com/signin/latest/APIReference/.

AWS Identity and Access Management (IAM) now offers three new global condition keys that will make it easier for you to establish a network perimeter. The new condition keys - aws:VpceAccount, aws:VpceOrgPaths, and aws:VpceOrgID - help you ensure that requests to your AWS resources or by your identities are made through your VPC endpoints. The condition keys provide you with varied levels of granularity, enabling you to implement your network perimeter controls at an account, organization path, and entire organization level. The controls automatically scale with your VPC usage, eliminating the need to enumerate VPC endpoints or update policies as you add or remove them. You can use these condition keys with both new and existing service control policies (SCPs), resource control policies (RCPs), resource-based policies, and identity-based policies. The condition keys are supported for a select set of AWS services and are available in all commercial AWS Regions where those services support AWS PrivateLink. To learn more about these new condition keys and supported services, please visit the AWS IAM documentation and AWS blog.

You can now connect AI agents directly to the AWS MCP Server using AWS Sign-In. Agents connect using industry-standard OAuth without requiring additional authentication software. Existing AWS identities, sign-in methods, IAM permissions, and governance controls you have already set up continue to apply. Developers can authorize agents interactively through a browser or programmatically using non-interactive (headless) authorization. Administrators can govern OAuth access using familiar IAM policies together with new OAuth capabilities, including global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events. To learn more, see the https://aws.amazon.com/blogs/security/introducing-oauth-support-for-aws-mcp-server/, https://docs.aws.amazon.com/signin/latest/userguide/oauth-sign-in-overview.html in the AWS Sign-In User Guide, and https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html in the Agent Toolkit for AWS User Guide.

AWS is expanding service reference information to include annotations for service actions, starting with action properties. Action properties provide context to indicate what an action is capable of, such as write or list capabilities, when you use it in a policy. Service reference information streamlines automation of policy management workflows, helping you retrieve available actions across AWS services from machine-readable files. Whether you are a security administrator establishing guardrails for workloads or a developer ensuring appropriate access to applications, you can now more easily identify the scope for each AWS service. You can automate the retrieval of service reference information, eliminating manual effort and ensuring your policies align with the latest service updates. You can also incorporate this service reference directly into your policy management tools and processes for a seamless integration. This feature is offered at no additional cost. To get started, refer to the documentation on programmatic service reference information.

Today, AWS Security Token Service (STS) is announcing support for digitally signing OpenID Connect (OIDC) JSON Web Tokens (JWTs) using Elliptic Curve Digital Signature Algorithm (ECDSA) keys. A digital signature guarantees the JWT’s authenticity and integrity and ECDSA is a popular, NIST-approved digital signature algorithm. When your identity provider (IdP) authenticates a user, it crafts a signed OIDC JWT representing that user’s identity. When your authenticated user calls the AssumeRoleWithWebIdentity API and passes their OIDC JWT, STS vends short-term credentials that enable access to your protected AWS resources. You now have a choice between using RSA and ECDSA keys when your IdP digitally signs an OIDC JWT. To begin using ECDSA keys with your OIDC IdP, update your IdP’s JWKS document with the new key information. No change to your AWS Identity and Access Management (IAM) configuration is needed to use ECDSA-based signatures of your OIDC JWTs. Support for ECDSA-based signatures of OIDC JWTs is available in all AWS Regions, including the AWS GovCloud (US) Regions . To learn more about using OIDC to authenticate your users and workloads, please visit OIDC Federation in the IAM Users Guide.

https://aws.amazon.com/iam/ has increased maximum quotas for six resources: Customer managed policies per account (5,000 to 10,000) Instance profiles per account (5,000 to 10,000) Managed policies per role (20 to 25) Role trust policy length (4,096 to 8,192 characters) Roles per account (5,000 to 10,000) OpenId connect providers per account (100 to 700) These updates address common scaling constraints customers encounter as their AWS environments grow. With these higher maximum quotas, customers have more flexibility to customize IAM controls and support additional workloads that require creation of IAM resources. Customers can view the latest IAM quotas in the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html documentation. To request quota increases for accounts in AWS commercial regions, use https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html in US East (N. Virginia). In AWS GovCloud (US) and China Regions, customers can request increases through AWS Support. For more information, see https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html in the Service Quotas User Guide.

AWS Identity and Access Management (IAM) now supports a new global condition key, aws:SourceVpcArn, that enables customers to enforce region-based access controls for resources accessed through https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html. This condition key returns the ARN of the VPC where the VPC endpoint is attached, allowing customers to verify whether requests travel through a specific VPC and implement controls on private access to their resources in same-region or cross-region scenarios. Customers can use aws:SourceVpcArn in policies to ensure resources are only accessible from VPC endpoints in specific regions, helping enforce data residency requirements. For example, you can attach a policy to an Amazon S3 bucket that restricts access to requests made through VPC endpoints in designated regions only. The aws:SourceVpcArn condition key is available in all commercial AWS Regions. For a complete list of supported AWS services and to learn more, please refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-network-properties

AWS Identity and Access Management (IAM) is launching temporary delegation, a new capability that helps you accelerate onboarding and simplify management for products from Amazon and AWS Partners that integrate with your AWS accounts. With today’s launch, you can safely delegate limited, temporary access to these product providers to perform initial deployments, ad-hoc maintenance, or feature upgrades on your behalf. This approach provides a more secure and streamlined experience by eliminating the need for you to create persistent IAM roles for such tasks, or perform them manually. It reduces your setup time and lowers your operational burden, while giving you complete control and auditability over delegated access and actions. This feature is available in all AWS commercial Regions. Amazon products and AWS Partners such as Amazon Leo (coming soon), Archera, Aviatrix, CrowdStrike (coming soon), Databricks, HashiCorp, Qumulo, Rapid7, and SentinelOne are already implementing AWS IAM temporary delegation. To get started, Customers: See the https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-temporary-delegation.html or https://aws.amazon.com/blogs/apn/streamline-customer-onboarding-and-accelerate-time-to-value-with-aws-iam-temporary-delegation/ AWS Partners: Refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-temporary-delegation-partner-guide.html for onboarding details

AWS Identity and Access Management (IAM) now offers three new global condition keys that will make it easier for you to establish a network perimeter. The new condition keys - aws:VpceAccount, aws:VpceOrgPaths, and aws:VpceOrgID - help you ensure that requests to your AWS resources or by your identities are made through your VPC endpoints. The condition keys provide you with varied levels of granularity, enabling you to implement your network perimeter controls at an account, organization path, and entire organization level. The controls automatically scale with your VPC usage, eliminating the need to enumerate VPC endpoints or update policies as you add or remove them. You can use these condition keys with both new and existing service control policies (SCPs), resource control policies (RCPs), resource-based policies, and identity-based policies. The condition keys are supported for a https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html and are available in all commercial AWS Regions where those services support AWS PrivateLink. To learn more about these new condition keys and supported services, please visit the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html and https://aws.amazon.com/blogs/security/use-scalable-controls-to-help-prevent-access-from-unexpected-networks/

https://aws.amazon.com/iam/ announces a major update to https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html, the tool you use to test and validate the permissions your IAM policies grant before you deploy them. This update changes the simulator in three ways: it now lives in the IAM console, it can test service control policies (SCPs), and it adds flexibility to model more of the scenarios that security and platform teams simulate in practice. IAM Policy Simulator is now part of the IAM console, replacing the standalone simulator site, so you can test policies in the same place you manage your identities and policies. You can also now include SCPs in your simulation to test how your organization's SCP hierarchy interacts with identity and resource policies, and through the API, test how condition keys such as Region restrictions and tag requirements affect the outcome. Finally, new flexibility lets you exclude specific policies to model "what if I remove this policy?" scenarios, and cross-account simulations now report per-policy decisions for identity and resource-based policies, with the matched statements returned for a denied request reflecting only the policies that drove the decision. Together, these changes help teams automate policy unit testing, detect over-permissive access, and validate guardrails with greater confidence. These features are available in all AWS Regions where IAM Policy Simulator is available. You can access IAM Policy Simulator in the IAM console by choosing Policy simulator in the navigation pane. To learn more, see the following resources: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html API reference on https://docs.aws.amazon.com/IAM/latest/APIReference/API_SimulatePrincipalPolicy.html and https://docs.aws.amazon.com/IAM/latest/APIReference/API_SimulateCustomPolicy.html

https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/ now provides a simplified experience for configuring application permissions to access AWS resources in separate accounts. With enhancements to EKS Pod Identity APIs, you can now seamlessly configure access to resources across AWS accounts by providing the resource account’s IAM details during the creation of the Pod Identity association. Your applications running in the EKS cluster automatically receive the required AWS credentials during runtime without requiring any code changes. EKS Pod Identity enables applications in your EKS cluster to access AWS resources across accounts through a process called https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html. When creating a Pod Identity association, you can provide two IAM roles — an https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html in the same account as your EKS cluster and a target IAM role from the account containing your AWS resources (like S3 buckets or DynamoDB tables). When your application pod needs to access AWS resources, it requests credentials from the EKS Pod Identity, which automatically assumes the roles through IAM role chaining to provide your pod with the necessary cross-account temporary credentials. This feature is available in all AWS Regions where Amazon EKS is available. To learn more, see https://docs.aws.amazon.com/eks/latest/userguide/assign-target-role.html.

https://aws.amazon.com/iam/roles-anywhere/ now provides the capability to configure Virtual Private Cloud (VPC) endpoint policies for the IAM Roles Anywhere CreateSession API. You can update your VPC endpoint policies to allow or deny the CreateSession operation. If CreateSession is not explicitly included in the Allow statement of your VPC endpoint policy or if you don’t allow all operations (for example, by specifying “rolesanywhere:*“ as the action), IAM Roles Anywhere will not return temporary AWS credentials for requests made through your VPC endpoint. The CreateSession API enables workloads running outside of AWS to obtain temporary AWS credentials using X.509 certificates to access AWS resources. Previously, VPC endpoint policies applied to all IAM Roles Anywhere API operations except CreateSession. This launch closes that gap, giving you consistent, fine-grained access control across all IAM Roles Anywhere API operations. This feature is available in all https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html where IAM Roles Anywhere is available, including the AWS GovCloud (US) Regions, AWS European Sovereign Cloud (Germany) Region, and China Regions. To learn more, see the https://docs.aws.amazon.com/rolesanywhere/latest/userguide/vpc-interface-endpoints.html.

AWS Identity and Access Management (IAM) announces outbound identity federation, enabling customers to securely federate their AWS identities to external services using short-lived JSON Web Tokens (JWTs). This allows customers to securely authenticate their AWS workloads with third-party cloud providers, SaaS providers, and self-hosted applications without using long-term credentials or implementing complex workarounds. Customers can now exchange their AWS IAM credentials for cryptographically signed, short-lived JSON Web Tokens (JWTs), providing a simple and secure mechanism for AWS workloads to access external services. These tokens contain rich context about the AWS workloads, enabling external services to implement fine-grained access control. Administrators can control access to token generation and enforce token properties (such as lifetime, audience and signing algorithms) using IAM policies and audit token usage using CloudTrail logs, allowing them to meet their organization’s security and compliance requirements. This capability is available in all AWS commercial Regions, AWS GovCloud (US) Regions, and China Regions. To get started, visit the list of resources below: Read the https://aws.amazon.com/blogs/aws/simplify-access-to-external-services-using-aws-iam-outbound-identity-federation Visit https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound.html

AWS Identity and Access Management (IAM) now supports a new global condition key, aws:SourceVpcArn, that enables customers to enforce region-based access controls for resources accessed through AWS PrivateLink. This condition key returns the ARN of the VPC where the VPC endpoint is attached, allowing customers to verify whether requests travel through a specific VPC and implement controls on private access to their resources in same-region or cross-region scenarios. Customers can use aws:SourceVpcArn in policies to ensure resources are only accessible from VPC endpoints in specific regions, helping enforce data residency requirements. For example, you can attach a policy to an Amazon S3 bucket that restricts access to requests made through VPC endpoints in designated regions only. The aws:SourceVpcArn condition key is available in all commercial AWS Regions. For a complete list of supported AWS services and to learn more, please refer to the IAM User Guide.

AWS is expanding service reference information to include which operations are supported by AWS services and which IAM permissions are needed to call a given operation. This will help you answer questions such as “I want to call a specific AWS service operation, which IAM permissions do I need?” You can automate the retrieval of service reference information, eliminating manual effort and ensuring your policies align with the latest service updates. You can also incorporate this service reference information directly into your policy management tools and processes for a seamless integration. This feature is offered at no additional cost. To get started, refer to the documentation on programmatic service reference information.