Stop rotating secrets. Start eliminating them. Credentials injected at the kernel level, federated with cloud providers, never in application memory.
A developer commits an AWS key to a public repo. A CI/CD runner gets compromised and every pipeline secret is exfiltrated. An intern's laptop has a .env file with production database credentials. Compromised credentials are the leading initial access vector in breaches — because secrets are everywhere, long-lived, shared, and painful to rotate.
A leaked credential means emergency rotation across every service that shares it. Manual coordination, restart cascades, and hours of uncertainty about blast radius.
Cloud IAM keys, registry tokens, and deploy credentials stored as pipeline secrets. Your CI/CD runners are the highest-value credential theft target in your infrastructure.
You deployed Vault for dynamic secrets, but now every service needs a sidecar or init container. That's hundreds of sidecars to configure, monitor, and troubleshoot when they fail.
Multiple services share the same service account key. When one is compromised, you don't know what's exposed until you've inventoried every consumer — which takes days.
Workloads make plain HTTP requests. Credentials are injected automatically before the request leaves the machine — the workload never sees, stores, or handles any secret. Cloud federation replaces long-lived IAM keys entirely — workloads exchange their identity for temporary, scoped cloud credentials.
Point to your credential providers: HashiCorp Vault, AWS IAM (via OIDC federation), GCP Workload Identity Federation, Azure federated identity, OAuth2 providers, or Kubernetes service account tokens.
CredentialBinding resources connect a source to a WorkloadIdentity, specifying which workload gets which credential and how it is delivered.
When a workload makes an outbound HTTP request, the right credential is injected automatically — Authorization headers, AWS SigV4 signatures, bearer tokens. The credential never enters application memory.
Credentials are short-lived and refreshed before expiration. No workload restart. No manual rotation. No coordination across teams.
Dynamic secrets from Vault or OpenBao, delivered through kernel-level injection. No sidecar, no init container, no token file to mount.
The built-in OIDC provider lets AWS, GCP, and Azure exchange Riptides-issued identity tokens for temporary, scoped credentials. No long-lived keys anywhere.
Each workload identity gets its own credential bindings. Compromise of one workload does not expose credentials for another.
No os.getenv(), no credential provider chain, no secret management library. The workload makes plain HTTP requests. The kernel handles the rest.
Pick one service that uses long-lived IAM keys. Enable the OIDC provider. Configure your cloud to accept Riptides-issued tokens. The service now gets temporary, scoped credentials — no keys stored anywhere. One service, one cloud provider, immediate value.
| Traditional | Riptides Secretless | |
|---|---|---|
| Where secrets live | Env vars, config files, K8s Secrets, process memory | Kernel space only |
| Cloud IAM keys | Long-lived access keys | None — OIDC federation for temporary credentials |
| Rotation | Manual, risky, requires restarts | Automatic, no restart, no coordination |
| Vault integration | Vault Agent sidecar + init container per service | Kernel-level injection; no sidecar |
| CI/CD credentials | Pipeline secrets, long-lived tokens | Process-level identity + OIDC federation |
| Blast radius | Shared service accounts; unknown scope | Unique bindings per workload identity |
| Code changes | SDK credential providers, getenv() | None |
| Audit posture | "We rotate quarterly" | "Credentials don't exist in application space" |
A blueprint for eliminating static credentials entirely, from design principles to kernel-level enforcement: Workload Identity Without Secrets: A Blueprint for the Post-Credential Era →
Broker- and proxy-based "secretless" tools route credentials through a sidecar or proxy process that your application connects to. The credential still exists somewhere in the request path — just in the proxy instead of your application. That proxy is a new attack surface, a new process holding the secret, and a new layer to misconfigure.
The distinction matters because a proxy is a user-space process. User-space processes can be inspected, attached to with a debugger, or have their memory read by other processes with sufficient privileges. Kernel-space injection operates below the user-space boundary entirely. There is no process an attacker can attach to, because the credential never lives in one.
Secretless infrastructure means workloads authenticate to services, databases, and cloud APIs without storing static credentials anywhere. Not in environment variables, not in config files, not as Vault lease values held in process memory. Each workload holds a cryptographic identity, and the credential is fetched and injected at the kernel level per request. The application never sees it.
This is different from secrets rotation, which still stores a credential and just changes it on a schedule. It is different from Vault dynamic secrets, which generate short-lived credentials but still deliver them into process memory where they can be read, logged, or exfiltrated. And it is different from cloud IAM federation, which removes keys for one cloud provider but does not generalize across clouds or to non-cloud services like databases and third-party APIs.
The key property is that no credential ever exists in application space. There is nothing to steal from a compromised process, nothing to rotate after a leak, and no blast radius to calculate. The workload identity is the authentication primitive, and every downstream call is authorized against it.
| Approach | Credential in memory? | Rotation required? | Works cross-cloud? |
|---|---|---|---|
| Static secrets | Yes | Yes | Yes |
| Vault dynamic secrets | Yes (briefly) | No | Requires Vault everywhere |
| Kernel identity injection | No | No | Yes (via SPIFFE federation) |
Secretless infrastructure means workloads authenticate to every service, database, and cloud API without storing static credentials anywhere. There are no API keys in environment variables, no passwords in config files, no tokens in mounted volumes. Each workload has a cryptographic identity, and credentials are issued just-in-time and injected at the kernel for each individual request.
No. Your secrets manager (Vault, AWS Secrets Manager, etc.) continues to store and manage credentials. What changes is how workloads access them. Instead of fetching and holding credentials themselves, workloads no longer touch secrets at all. Riptides intercepts outbound requests, fetches the credential on the workload's behalf, and injects it in kernel space. The secret never enters application memory.
Riptides is designed for incremental adoption. Start with one service in permissive mode to observe what credentials it uses and where it connects. Then enable secretless injection for those credential bindings. The application code does not change. You remove the static credential from the environment and let Riptides handle injection. Roll out one service at a time.
If the Riptides kernel module is not present, requests proceed without credential injection. This means the downstream service will receive an unauthenticated request and likely reject it. You can configure fallback behavior in your policy, such as failing closed for sensitive services or failing open for non-sensitive ones. The module is stateless per-node, so node reboots do not require re-initialization.
Yes. Riptides runs on any Kubernetes distribution and gives every pod, service, and job a SPIFFE identity, so credentials never have to be mounted as env vars, ConfigMaps, or volumes. It replaces Vault Agent Injector sidecars and init containers — injection happens at the kernel instead of in a per-pod sidecar. It works alongside Kubernetes Secrets and federates to AWS via IAM Roles Anywhere, GCP via Workload Identity Federation, and Azure via federated managed identity.
Broker- and proxy-based tools route requests through a sidecar or proxy process that fetches and holds the credential, so the secret still lives in a user-space process you can attach to or read. Riptides injects the credential in kernel space, below the user-space boundary. The credential never exists in any user-space process memory, there is no proxy to point applications at, and no new privileged process to defend.
Identity, access control, and a full audit trail for every agent and service — enforced on the host, with no code changes. Up and running in an afternoon.