The shared secrets like passwords and API keys are easy to use but bring higher risk. The long-lived nature of these powerful credentials can cause monumental damage to any organization.

Our industry has worked hard to eliminate the shared secret model and move towards short-lived, right-sized credentials that do not slow down developer velocity while mitigating security risks. Software pipelines and automated workflows are power tools for every DevOps team to manage their cloud infrastructure and workloads.

This blog will look at how Britive’s PAM for Cloud, helps secure your workloads.

Federated workload identities have become the industry standard. For us, at Britive it was a simple decision to adopt this model and enhance it with our unique policy-based authorization framework.

Every leading platform today supports workload federation, e.g. AWS STS, GCP’s workload identity, or OIDC support provided by GitHub, SpaceLift, and GitLab. Services can leverage these authentication mechanisms to gain the right short-lived privileges to various cloud and SaaS services.

Britive’s Federated Access Process for Workloads

Let’s look at the workflow in more detail.

  • The workload fetches a signed ID token for authentication that asserts its identity for Britive. Typically, a JSON Web Token (JWT) token. These ID Tokens are short-lived and created at each execution of the workload.
  • Britive verifies the asserted identity and evaluates access policies for the federated service principal.
  • Britive creates a short-lived service principal upon policy evaluation at the requested CSP and adds the verified permissions.
  • Once the credentials and permissions have been created, Britive shares these credentials with the requesting workload. Essentially, granting ephemeral access keys in exchange for a short-lived identity token.
  • The workload carries out its required actions with the said credentials.
  • Once the task is complete or time expires, Britive destroys the service principal, achieving true zero-standing privileges.

Britive acts as an authorization broker, creating a short-lived service principal with only the right level of access. These service principals are destroyed after their intended use, achieving zero-standing privileges and no lingering accounts to take over. This makes Britive’s solution superior to other federation providers.

This GitHub actions example demonstrates this capability. This workflow does not carry any stored secrets and leverages PyBritive to check out the required permissions to update the AWS S3 bucket with an updated HTML file.

To see how Britive’s innovative approach to federated workload identities can enhance your security while maintaining developer velocity, schedule some time to see our platform in action. Our policy-based authorization framework ensures zero standing privileges and secure, short-lived service principals.

Author