Extend trust across clouds, clusters, and organizations. No shared secrets, no VPNs, no credential distribution.
Two organizations need to talk. Or two clouds. Or two clusters that weren't supposed to need each other until last quarter. The solution is always the same: someone sets up a VPN, distributes shared credentials, or opens a firewall rule that's too broad — and then it stays that way forever.
A VPN tunnel lets traffic flow between environments, but once inside, there is no workload-level authentication. The tunnel becomes a trust boundary with no trust enforcement.
AWS IAM, GCP IAM, and Azure AD are separate identity universes. A workload in one cloud cannot natively prove its identity to a workload in another — or to anything on-premises.
Connecting services across Kubernetes clusters means distributing API keys, certificates, or tokens. Each new cluster multiplies the sprawl — and the blast radius.
Migrating to a shared identity platform takes quarters. Distributing shared credentials is immediate risk. Most teams pick the risk and call it temporary.
Two environments exchange public certificates — not shared secrets. Workloads in one domain can now verify identities from the other. A built-in OIDC provider integrates with any system that supports OIDC — cloud IAM, CI/CD platforms, SaaS APIs, partner systems.
Each Riptides deployment has its own trust domain. To connect them, exchange public certificates — not shared secrets. Workloads in one domain can now verify identities from the other.
Riptides issues standard OIDC tokens for your workloads. Any system that supports OIDC — AWS, GCP, Azure, CI/CD platforms, SaaS APIs — can validate them natively.
Workloads exchange their Riptides identity for temporary, scoped cloud credentials from AWS, GCP, or Azure. No IAM keys stored anywhere.
For legacy systems, third-party APIs, and SaaS platforms, Riptides issues signed tokens that carry the workload's identity and can be verified against a standard OIDC endpoint.
Trust is established by exchanging public root CA certificates, not by distributing keys or credentials. Compromising one domain does not yield credentials for another.
Workloads authenticate directly to each other with mTLS, regardless of network path. The VPN can remain for connectivity; identity no longer depends on it.
Two organizations exchange trust bundles. Cross-organization service communication is secured in days — with full identity-based access control from the start.
On-premises, edge, and multi-cloud workloads all use the same OIDC federation mechanism for temporary cloud access. No IAM keys stored anywhere.
Pick one cluster. Enable the OIDC provider. Configure AWS, GCP, or Azure to accept Riptides-issued tokens. Your workloads now get temporary, scoped cloud credentials — no IAM access keys stored anywhere. One cluster, one cloud provider, no cross-org coordination needed.
| Traditional | Riptides Federation | |
|---|---|---|
| Trust mechanism | Shared secrets, VPN tunnels, API keys | Trust bundle exchange (public CA certs) |
| Identity across clouds | Cloud-specific IAM, no interoperability | SPIFFE IDs portable across any environment |
| Cloud credential access | Long-lived IAM keys per environment | OIDC federation for temporary credentials |
| Cross-cluster auth | Shared secrets or unified mesh control plane | Independent control planes, federated trust |
| Integration timeline | Weeks to months | Days |
| Revocation | Rotate shared secrets everywhere | Remove trust bundle or identity |
| Standards | Proprietary per vendor | SPIFFE, OIDC, X.509 |
| Audit posture | "We have VPN tunnels between environments" | "Every cross-boundary connection is cryptographically authenticated" |
Kernel-level identity and enforcement. No code changes. Deploy in minutes.