# SPIFFE Published articles for SPIFFE. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE DevFeed: [The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE]() Original publisher: [Read original article]() Author: Eviatar Garzi Published: 2026-09-10T10:00:43Z Content type: article Language: en Sources: [Unit 42]() Topics: [Kubernetes]() Tags: [api](), [containers](), [cryptographic](), [identity](), [json](), [kubernetes](), [linux](), [malware](), [node](), [open-source](), [research](), [secrets](), [spiffe](), [spire](), [spoof](), [spoofing](), [threat-research](), [tool]() ### AI overview Research on a post-exploitation technique in which root access to a Kubernetes node can let an attacker spoof cgroup metadata used by SPIRE workload attestation, impersonate co-located workloads, and obtain SVIDs. ### Source excerpt Learn how root access on a compromised K8s node allows attackers to utilize SPIFFE/SPIRE metadata to spoof and harvest co-located workload identities. The post The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE appeared first on Unit 42. ## Security Baked Into the JVM: two Subjects, one call DevFeed: [Security Baked Into the JVM: two Subjects, one call]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-08-09T00:00:00Z Content type: article Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [SPIFFE](), [SPIRE]() Tags: [certificates](), [dirtychai](), [java](), [jgdms](), [jini](), [jvm](), [jwt](), [microservices](), [oidc](), [permission](), [process](), [security](), [spiffe](), [spire](), [technical]() ### AI overview This article examines identity and security in the JVM through DirtyChai. It describes separate process and user identities, including SPIFFE workload credentials delivered through SPIRE and JWT/OIDC-based user identity, and explains how these identities coexist across request dispatch and privilege boundaries. ### Source excerpt The constraint system stops a bad call before it leaves the JVM. The Safe Codebase Audit Pipeline stops bad code before a client ever loads it. What remains is identity: who is calling, and can you verify it? Most frameworks answer with a token check at the door. A filter validates a bearer token, sets a thread-local variable, and hopes that nothing downstream forgets to look at it. DirtyChai answers differently. ## Zero trust architecture for platform engineers: Securing modern developer platforms DevFeed: [Zero trust architecture for platform engineers: Securing modern developer platforms]() Original publisher: [Read original article]() Author: Ajay Chankramath Published: 2026-07-23T05:40:01Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [Zero Trust](), [Security](), [Architecture & Design](), [Platform Engineering](), [Authentication](), [Authorization](), [Cloud](), [Kubernetes](), [Network Segmentation](), [SPIFFE](), [SPIRE]() Tags: [architecture](), [authentication](), [authorization](), [cloud](), [cloud-native](), [developer](), [identity](), [kubernetes](), [network-segmentation](), [platform](), [platform-engineering](), [policy](), [security](), [spiffe](), [spire](), [zero-trust]() ### AI overview This article explains how zero-trust architecture secures cloud-native developer platforms. It describes continuous authentication and authorization, cryptographic service identity through SPIFFE/SPIRE, network segmentation, policy-as-code enforcement, and runtime verification for Kubernetes-based, multi-tenant environments. ### Source excerpt Secure your cloud-native platform with Zero Trust Architecture. Explore ZTA principles, service identity (SPIFFE/SPIRE), and policy-as-code for automated, developer-friendly security ## Kubernetes for Agentic AI: Best Practices for Identity and Access DevFeed: [Kubernetes for Agentic AI: Best Practices for Identity and Access]() Original publisher: [Read original article]() Author: info@goteleport.com (Boris Kurktchiev, Megan Moore) Published: 2026-07-07T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [Artificial Intelligence](), [Kubernetes](), [Authentication](), [audit](), [SPIFFE](), [OpenID connect (OIDC)](), [Cloud Native Ecosystem]() Tags: [agent-identity](), [agentic-ai](), [audit](), [cloud-native](), [identity](), [kubernetes](), [least-privilege](), [oidc](), [spiffe](), [technical]() ### AI overview This article explains when autonomous or long-running agents in Kubernetes need distinct workload identities instead of inheriting a user's identity. It recommends least-privilege access, short-lived credentials, re-authentication for sensitive actions, network enforcement, and auditability. ### Source excerpt When agents act autonomously beyond a user's session, they need their own identity, least-privilege access, and full audit trails. ## What SPIFFE Answers for Workload Identity and What It Doesn't DevFeed: [What SPIFFE Answers for Workload Identity and What It Doesn't]() Original publisher: [Read original article]() Author: info@goteleport.com (Rob Cobbins) Published: 2026-05-29T00:00:00Z Content type: opinion Language: en Sources: [Teleport]() Topics: [SPIFFE](), [Authorization](), [active directory](), [AWS IAM](), [passwd](), [OpenID connect (OIDC)](), [saml]() Tags: [active-directory](), [authorization](), [aws](), [identity](), [ldap](), [oidc](), [passwd](), [permissions](), [saml](), [spiffe]() ### AI overview This article examines what SPIFFE provides for workload identity and where it falls short. It argues that SPIFFE offers a sound way for machines to prove their identities without shared secrets, but does not define authorization and leaves workload registration largely to implementations. ### Source excerpt Learn about the workload identity questions SPIFFE can't answer and considerations for filling gaps in the spec. ## How to Extend SPIFFE Beyond Kubernetes: Bring Zero Trust Identity to Your VMs DevFeed: [How to Extend SPIFFE Beyond Kubernetes: Bring Zero Trust Identity to Your VMs]() Original publisher: [Read original article]() Author: info@goteleport.com (Jeffrey Ellin) Published: 2026-05-21T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [SPIFFE](), [Zero Trust](), [certificates](), [istio](), [Kubernetes]() Tags: [api](), [certificates](), [istio](), [kubernetes](), [mesh](), [spiffe](), [zero-trust]() ### AI overview This tutorial explains how to extend SPIFFE-based zero-trust workload identity beyond Kubernetes to VMs, edge gateways, and legacy services. It describes separating identity issuance from consumption, using short-lived identities through a local API, with Envoy consuming identity via SDS and Teleport managing the trust chain. ### Source excerpt Discover how Envoy + SDS and Teleport Workload Identity let off-cluster workloads securely call Istio services without distributing certificates. ## Guide: How to Unify Identity Across Cloud and Data Center Infrastructure DevFeed: [Guide: How to Unify Identity Across Cloud and Data Center Infrastructure]() Original publisher: [Read original article]() Author: info@goteleport.com (Mayur Pipaliya) Published: 2026-05-01T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [IAM](), [trust](), [certificates](), [SPIFFE](), [Cloud](), [data centers](), [Amazon Web Services](), [Entra ID]() Tags: [certificates](), [cloud](), [critical-infrastructure](), [data-center](), [entra-id](), [identity](), [identity-and-access](), [infrastructure](), [spiffe]() ### AI overview This guide explains identity fragmentation across cloud accounts, data centers, and colocated infrastructure. It describes siloed identity systems, credential sprawl, and differing access models, and presents approaches including hardware roots of trust, short-lived certificates, shared certificate authorities, SPIFFE workload identities, reverse tunnels, and protocol-level enforcement. ### Source excerpt Inside this guide, discover the root causes of identity fragmentation across cloud and data center environments -- and what it takes to unify identity. ## Keycloak 26.5.6 released DevFeed: [Keycloak 26.5.6 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-03-19T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Security](), [Authorization](), [OpenID connect (OIDC)](), [Authentication]() Tags: [2026](), [access-control](), [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oidc](), [openid-connect](), [race-condition](), [release](), [saml](), [security](), [spiffe](), [sso]() ### AI overview Keycloak 26.5.6 was released on March 19, 2026. The release includes security fixes for issues including SSRF, refresh-token reuse bypass, improper access control, privilege escalation, authorization bypass, and information disclosure, along with other bug fixes. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Security fixes #45645 CVE-2026-1180 - Blind Server-Side Request Forgery (SSRF) in Keycloak OIDC Dynamic Client Registration via jwks_uri oidc #45647 CVE-2026-1035 - Keycloak Refresh Token Reuse Bypass via TOCTOU Race Condition oidc #45650 CVE-2025-14777 - Keycloak IDOR in realm client creating/deleting #45653 CVE-2025-14082 keycloak-server: Keycloak Admin REST API: Improper Access Control leads to sensitive role metadata information disclosure #46719 CVE-2026-3121 - Keycloak: Privilege escalation via manage-clients permission #46723 CVE-2026-3190 - Information Disclosure via improper role enforcement in UMA 2.0 Protection API core #46922 CVE-2026-3911 Keycloak: Information disclosure of disabled user attributes via administrative endpoint user-profile #47062 CVE-2026-2366 Authorization Bypass: Unprivileged tokens can enumerate user organization memberships organizations Bugs #45889 Federated user disabled when external DB unavailable, never re-enabled storage #46239 AUTH_SESSION_ID cookie reuse causes cross-user session contamination on re-authentication authentication #46296 UsersResource.search briefRepresentation started to return user attributes admin/api #46379 Unexpected error when logging out with offline session and external IDP oidc #46459 Operator-built DB config: targetServerType=primary not applied / connection validation not working after master-replica failover (26.5.0) operator #46588 Partial LDAP sync duration does not follow the defined value in user federation ldap #46605 26.5.4 startup regression with many realms: RealmCacheSession.prepareCachedRealm() scans master admin role composites per realm (O(N²)) core #46656 Em-Hyphens in SPI options on cache configuration page docs #46663 JGroups bind port configuration ignored when --cache-embedded-network-bind-port set infinispan #46669 SPIFFE Clie ## CockroachDB Plans Native X.509 SAN Support for SPIFFE and SPIRE Integration DevFeed: [CockroachDB Plans Native X.509 SAN Support for SPIFFE and SPIRE Integration]() Original publisher: [Read original article]() Author: Sanchit Khanna,Biplav Saraf Published: 2026-03-13T00:00:00Z Content type: article Language: en Sources: [Cockroach Labs]() Topics: [CockroachDB](), [Databases](), [SPIFFE](), [SPIRE](), [certificates](), [Zero Trust](), [Security](), [Microservice]() Tags: [architectures](), [auditability](), [aws-iam](), [certificates](), [cockroachdb](), [compliance](), [cryptographic](), [database](), [distributed](), [processor](), [regex](), [security](), [soc](), [soc-2](), [spiffe](), [spire](), [standards](), [teams](), [verification](), [zero-trust]() ### AI overview The article previews planned CockroachDB authentication support for Subject Alternative Name fields in X.509 certificates. It explains how SAN support is intended to enable integration with SPIFFE and SPIRE and support regex-based identity mapping for cloud-native workloads. ### Source excerpt In the evolution of cloud-native security, identity has become the new perimeter. ## How to Secure Microservices with SPIFFE and Istio DevFeed: [How to Secure Microservices with SPIFFE and Istio]() Original publisher: [Read original article]() Author: info@goteleport.com (Jeff Ellin, Boris Kurktchiev) Published: 2026-02-20T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [istio](), [Microservices](), [SPIFFE](), [Zero Trust](), [Authorization](), [Architecture & Design](), [Secrets Management](), [certificates]() Tags: [architecture](), [authorization](), [backend](), [certificates](), [cloud-native](), [firewalls](), [how-to](), [istio](), [kubernetes](), [microservices](), [policies](), [secrets-management](), [security](), [service-mesh](), [spiffe](), [zero-trust]() ### AI overview This guide explains how to secure microservices with SPIFFE identities, Istio service-mesh mTLS, short-lived certificates, and Zero Trust authorization policies. It addresses the limits of network-based trust and long-lived certificates in dynamic Kubernetes environments. ### Source excerpt Learn how to deploy a secure microservices application, configure default-deny authorization policies, and rebuild service connectivity with SPIFFE-based allow rules. ## Meet Keycloak at KubeCon EU, Amsterdam in March 2026 DevFeed: [Meet Keycloak at KubeCon EU, Amsterdam in March 2026]() Original publisher: [Read original article]() Author: Alexander Schwartz Published: 2026-02-07T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [Authorization](), [Kubernetes](), [OpenTelemetry](), [SPIFFE]() Tags: [2026](), [authentication](), [authorization](), [conference](), [event](), [idm](), [kerberos](), [keycloak](), [kubecon](), [kubecon-eu](), [kubernetes](), [ldap](), [openid-connect](), [opentelemetry](), [saml](), [spiffe](), [sso](), [talks]() ### AI overview Keycloak announces its participation in KubeCon EU Amsterdam in March 2026, including KeycloakCon, a Project Pavilion kiosk, and talks covering identity management, authentication, authorization, observability, and federated identity in cloud-native environments. ### Source excerpt The Keycloak project is back at KubeCon EU Amsterdam with all highlights: Talks, our kiosk in the Project Pavilion, and this time also with KeycloakCon, our very-own co-located event! If you are new to Keycloak, or already a user, join us for this exciting event to learn and connect. Half-day KeycloakCon packed with all-things-Keycloak KeycloakCon is a co-located event happening on Monday, March 22 from 09:00 to 12:30. It brings together the Keycloak community with case studies and talks featuring the latest features. Join this event for technical talks, professional growth, and networking opportunities. Book your ticket as part of the All-Access In-Person KubeCon + CloudNativeCon pass. & & & & '' ## Keycloak Federated Client Authentication with External Identity Providers DevFeed: [Keycloak Federated Client Authentication with External Identity Providers]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2026-01-26T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [JSON Web Tokens](), [openid](), [SPIFFE](), [Kubernetes](), [trust]() Tags: [authentication](), [idm](), [jwt](), [kerberos](), [keycloak](), [kubernetes](), [ldap](), [lookup](), [openid](), [openid-connect](), [saml](), [signing](), [spiffe](), [sso](), [token](), [verify]() ### AI overview Keycloak's federated client authentication lets OpenID Connect clients authenticate through external identity providers such as OpenID Connect, SPIFFE, and Kubernetes. The article explains trust relationships, JWT claims, token verification, and how this can reduce the need for client-managed secrets in some environments. ### Source excerpt Keycloak has from day one supported identity brokering, allowing users to authenticate via an external OpenID Connect or SAML 2.0 identity provider. With federated client authentication it is now possible to authenticate OpenID Connect clients through external identity providers as well. Depending on the environment the clients is running in this can eliminate the need for managing secrets for clients altogether. A number of cloud vendors for example support injecting tokens automatically for workloads, Kubernetes have support for service accounts, and last but not least there is SPIFFE that can be leveraged in most environments. How does federated client authentication work? The first step to setting up federated client authentication is to define a trust relationship between Keycloak and the external identity providers. This is done by creating a new identity provider in the realm. Keycloak currently has three types of identity providers that support federated client authentication: OpenID Connect SPIFFE Kubernetes Clients can retrieve a token from the external identity providers that the client can then use to authenticate with Keycloak. In many cases clients can retrieve these tokens automatically through workload identity capabilities enabled for particular environments. Let's look at an example decoded JWT that can be used to authenticate a client: { "iss" : "https://my-external-idp" "aud" : [ "http://my-keycloak/realms/myrealm" ], "exp" : 1769149961, "iat" : 1769149661, "sub" : "client-id-in-my-external-idp" } The most relevant claims are iss, aud and sub. Keycloak uses the iss claim to identity the external party that issued the token as well as retrieving the external parties signing keys to verify the token. The aud claim is to make sure the token was issued to be used by Keycloak and not other applications. It is important that this contains a single audience that uniquely identifies Keycloak as the target audience, as leaking this token to other parties ## Keycloak 26.4.2 released DevFeed: [Keycloak 26.4.2 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-10-23T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [upgrade](), [version](), [OpenID connect (OIDC)](), [SPIFFE](), [PostgreSQL]() Tags: [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oidc](), [openid-connect](), [postgresql](), [release](), [saml](), [spiffe](), [sso](), [upgrade](), [version](), [vulnerability]() ### AI overview Keycloak 26.4.2 was released on October 23, 2025. The release includes documentation and user-profile enhancements, SPIFFE support for an OIDC JWK endpoint, and fixes for CI, authentication, identity brokering, admin UI, documentation links, and graceful server shutdown. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Enhancements #42991 Final review and update for UPDATE_EMAIL documentation docs #43351 Make pending email verification attribute removable by admin user-profile #43650 SPIFFE should support OIDC JWK endpoint Bugs #26374 Workflow failure: Quarkus IT - FipsDistTest#testUnsupportedHttpsPkcs12KeyStoreInStrictMode ci #30939 Vulnerability in brute force detection settings authentication #43022 Incorrect Basic Auth encoding for OIDC IDentity Provider when Client ID contains colon identity-brokering #43191 Upgrade guide for 26.4.0 should mention new minimal PostgreSQL server version 13 requirement docs #43244 UI crash on admin `/users/add-user` since 26.4.0 admin/ui #43544 Intra-document links not rendered in downstream docs #43561 Server does not shutdown gracefully when started with --optimized core ## Keycloak 26.4.0 released DevFeed: [Keycloak 26.4.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-09-30T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Passkeys](), [Security](), [OAuth 2.0](), [Specifications](), [SPIFFE](), [Kubernetes](), [OpenID connect (OIDC)](), [REST API](), [Availability]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [release](), [rest-api](), [saml](), [security](), [specifications](), [spiffe](), [sso](), [version]() ### AI overview Keycloak 26.4.0 introduces passkeys, federated client authentication using SPIFFE or Kubernetes service account tokens, support for final FAPI 2.0 specifications, and full DPoP support. The release also includes availability and administration improvements. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities focused on security enhancements, deeper integration, and improved server administration. The highlights of this release are: Passkeys for seamless, passwordless authentication of users. Federated Client Authentication to use SPIFFE or Kubernetes service account tokens for client authentication. Simplified deployments across multiple availability zones to boost availability. FAPI 2 Final: Keycloak now supports the final specifications of FAPI 2.0 Security Profile and FAPI 2.0 Message Signing. DPoP: The OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) is now fully supported. Improvements include the ability to bind only refresh tokens for public clients, and securing all Keycloak endpoints with DPoP tokens. Read on to learn more about each new feature. If you are upgrading from a previous release, review also the changes listed in the upgrading guide. Security and Standards Passkeys integration (supported) Passkeys are now seamlessly integrated in the Keycloak login forms using both conditional and modal UIs. To activate the integration in the realm, go to Authentication, Policies, Webauthn Passwordless Policy and switch Enable Passkeys to enabled. For more information, see Passkeys. FAPI 2 Final (supported) Keycloak has support for the latest versions of FAPI 2 specifications. Specifications FAPI 2.0 Security Profile and FAPI 2.0 Message Signing are already promoted to Final and Keycloak supports them. Keycloak client policies support the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite. Apart from some very minor polishing of existing policies, Keycloak has new client profiles (fapi-2-dpop-security-profile and fapi-2-dpop-message-signing) for the clients that use DPoP and are intended to be FAPI 2 compliant. Thank you to Takashi Norimatsu for contributing this. For more details, see the ## Teleport Workload Identity DevFeed: [Teleport Workload Identity]() Original publisher: [Read original article]() Author: ben@goteleport.com (Ben Arent) Published: 2024-04-11T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [SPIFFE](), [SPIRE](), [Security](), [Architecture & Design](), [Microservice](), [TLS (Transport Layer Security)](), [Zero Trust]() Tags: [api](), [bootstrapping](), [identity](), [preview](), [security](), [services](), [spiffe](), [spire](), [tls](), [x509](), [zero-trust]() ### AI overview An introduction to Teleport Workload Identity, a preview feature that bootstraps and issues identities to services across heterogeneous environments and organizational boundaries. It builds on SPIFFE and adds a SPIFFE workload API endpoint, SVID issuance, TPM server attestation, and AWS Roles Anywhere support. ### Source excerpt An introduction to Teleport Workload Identity, a preview feature for bootstrapping and issuing identities to services across heterogeneous environments. ## Connecting Block Business Units with AWS API Gateway DevFeed: [Connecting Block Business Units with AWS API Gateway]() Original publisher: [Read original article]() Author: Michael Weissbacher Published: 2023-05-18T13:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Amazon API Gateway](), [Amazon Web Services](), [Security](), [SPIFFE](), [SPIRE]() Tags: [api-gateway](), [aws](), [aws-api-gateway](), [engineering](), [network](), [security](), [spiffe](), [spire]() ### AI overview This article explains how Block integrates acquired companies with its internal service mesh using AWS API Gateway as an identity translation layer. The Farcars infrastructure maps acquisition-native identities and IAM-based SigV4 calls to Block-native mutual TLS, enabling isolated and reusable cross-mesh communication. ### Source excerpt Secure cross-mesh communication using in-mesh bastions ## How we Integrated SPIFFE, Oauth2.0 and Spring Boot DevFeed: [How we Integrated SPIFFE, Oauth2.0 and Spring Boot]() Original publisher: [Read original article]() Author: Matthew Benedict Stocks Published: 2022-12-14T09:36:48Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [SPIFFE](), [Authorization](), [OpenID connect (OIDC)](), [SPIRE](), [Library](), [Security](), [Spring Boot]() Tags: [authorization](), [cybersecurity](), [library](), [oauth2](), [platform](), [security](), [service-mesh](), [spiffe](), [spring-boot]() ### AI overview Wise's Security Engineering team describes how it consolidated SPIFFE/SPIRE and OIDC authorization strategies into the wise-security shared library. The approach reduces Spring Security boilerplate, presents a consistent service-layer security context, and adds guardrails intended to reduce misconfiguration and authorization complexity. ### Source excerpt How we Integrated SPIFFE, OAuth2 and Spring Boot At Wise the Security Engineering team supports the Security Squad by developing tools and building technical controls relevant to the security maturity of existing technological setup. We work closely with teams across Platform and Product to help improve our overall security posture and reduce the friction encountered when engineering new software at speed. Photo by Jason Dent on UnsplashThe problem As a company we have a goal of reducing the amount of time it takes to go from inception to creation with our services. We want teams across Wise to be able to focus on the challenges encountered in their domain, rather than cross-cutting concerns, such as how to secure their endpoints. At Wise our approach was to create a common shared library, allowing teams to share our security solution while still retaining their autonomy. Standard security setups such as those seen with Spring Security often require a lot of boilerplate code (even if provided as part of a service template) which we wanted to reduce and where possible, abstract it entirely. Along with improving the quality of life for new and experienced engineers within Wise, this also helps to prevent any misconfiguration that could eventually lead to a vulnerability. Another challenge which arose was to offer a security context that appears the same at the service layer, but can be created from any of the protocols used by our systems, as well as being extensible if necessary. We needed to allow developers to control access to services with minimal effort, alongside creating a security guardrail for exposed endpoints to ensure services have been configured correctly. Introducing Wise Security At Wise, our service mesh layer is handled by Envoy and the identity framework for secure communication between mesh nodes is SPIFFE/SPIRE. User based IAM is handled via the OIDC authorization protocol. Each authorization approach must be enforced at the service layer, but du ## AWS OIDC Authentication with SPIFFE DevFeed: [AWS OIDC Authentication with SPIFFE]() Original publisher: [Read original article]() Author: Roy Xu Published: 2021-08-26T19:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Amazon Web Services](), [OpenID connect (OIDC)](), [SPIFFE](), [SPIRE](), [Security](), [Secrets Management](), [Authentication](), [datacenter](), [Amazon S3](), [Amazon Simple Queue Service (SQS)](), [migration]() Tags: [app](), [authorization](), [automated](), [aws](), [cloud](), [datacenter](), [engineering](), [kubernetes](), [oidc](), [s3](), [secrets-management](), [security](), [spiffe](), [spire](), [sqs]() ### AI overview Square describes using SPIFFE and SPIRE's OIDC Discovery Provider to exchange SPIFFE JWTs for AWS credentials, allowing datacenter applications to assume AWS roles through an automated configuration-based process. ### Source excerpt Easy authentication with automated AWS credentials ## Expanding Secrets Infrastructure to AWS Lambda DevFeed: [Expanding Secrets Infrastructure to AWS Lambda]() Original publisher: [Read original article]() Author: Michael Weissbacher Published: 2021-08-04T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [AWS Lambda](), [migration](), [SPIFFE](), [Terraform](), [Cloud](), [Serverless]() Tags: [availability](), [aws-lambda](), [cloud](), [cloud-migration](), [engineering](), [security](), [serverless](), [spiffe](), [terraform]() ### AI overview The article describes how Square extended its data-center secrets infrastructure to AWS Lambda. It explains the addition of SPIFFE compatibility and a Lambda secrets syncer deployed through a Terraform module, while keeping secrets in Keywhiz and caching them in AWS Secrets Manager for cloud-native services. ### Source excerpt Extending our data center to the cloud ## Providing mTLS Identities to Lambdas DevFeed: [Providing mTLS Identities to Lambdas]() Original publisher: [Read original article]() Author: Michael Weissbacher Published: 2020-08-25T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [AWS Lambda](), [TLS (Transport Layer Security)](), [SPIFFE](), [SPIRE](), [Security](), [Authentication](), [datacenter](), [Microservice](), [Serverless](), [AWS IAM]() Tags: [audit-trail](), [authentication](), [aws-lambda](), [engineering](), [identity](), [microservices](), [secrets](), [security](), [serverless](), [spiffe](), [spire](), [tls]() ### AI overview Square describes a system that gives AWS Lambda applications short-lived, SPIFFE-compatible certificates for authenticated calls to microservices in its data centers. The design uses mutual TLS, AWS Private Certificate Authority, Secrets Manager, IAM policies, and advance certificate issuance to preserve security while keeping Lambda cold starts low. ### Source excerpt Securing severless communication with our data centers