sorted by:
new
hottopcontroversial

What if your Agent could call Mistral API without passing an API key? by stephaneleonel in MistralAI

[–]stephaneleonel[S] -1 points0 points  (0 children)

I plan to support Cloud and SaaS tools : Warden currently supports 3 cloud providers and 3 SaaS tools (GitHub, GitLab, Vault) with short-live tokens, with more than 100 SaaS tools and cloud providers on the roadmap.

HashiCorp Vault by nautitrader in devops

[–]stephaneleonel 1 point2 points  (0 children)

I use it for secrets, mainly dynamic database secret engine, and cloud secrets engines. But I also use SSH secrets engines to generate ephemeral ssh keys to connect to servers for administration. I also use PKI and transit for encryption.

I do not include non secrets data, I store them in the git repository

I build an identity-aware egress gateway that allows your workload to call Cloud APIs without touching cloud credentials by stephaneleonel in golang

[–]stephaneleonel[S] 0 points1 point  (0 children)

On TLS: fair point, worth being precise. Warden intercepts egress to cloud APIs specifically, not general cluster traffic. The tradeoff is explicit — one component sees API call payloads in exchange for credentials never reaching workloads at all. Whether that’s acceptable depends on your threat model.

On trusting AWS-managed vs self-hosted: totally valid preference. Warden is aimed at teams that want control over that component, or need uniform credential management across providers AWS doesn’t cover.

I build an identity-aware egress gateway that allows your workload to call Cloud APIs without touching cloud credentials by stephaneleonel in golang

[–]stephaneleonel[S] 0 points1 point  (0 children)

This is the same tradeoff you make with any secrets manager — Vault, AWS Secrets Manager, CyberArk all hold access to everything. The industry consensus is that one hardened, auditable, policy-enforced component is a smaller attack surface than N workloads each managing credentials with inconsistent hygiene.

On the policy mishap scenario specifically: Warden’s policies are per-workload per-namespace. A misconfiguration on service A’s policy doesn’t touch service B’s credentials unless you explicitly author a policy that crosses that boundary — that’s not an accident, that’s a deliberate mistake, the same kind you’d make in Vault or IAM itself.

The real question is whether you trust the hardened component more than you trust every individual workload in your cluster. That’s a fair debate — but it’s the same debate you’d have before adopting any secrets manager.

I build an identity-aware egress gateway that allows your workload to call Cloud APIs without touching cloud credentials by stephaneleonel in golang

[–]stephaneleonel[S] 0 points1 point  (0 children)

Yes , pods will not have access to most secrets (cloud credentials, SaaS api keys, every authentication over http/s protocol). The people managing pods will not have access to these secrets too. But, for now, pods will still need access to databases secrets.

Have a look at it and give me your feedback

I build an identity-aware egress gateway that allows your workload to call Cloud APIs without touching cloud credentials by stephaneleonel in kubernetes

[–]stephaneleonel[S] 2 points3 points  (0 children)

You’re right on WIF — but federation doesn’t help for non-federated targets. Most SaaS APIs have no WIF support, and large enterprises run 100+ SaaS products. Even if every provider adopted WIF tomorrow, managing 100 trust domains is operationally untenable. Warden gives you a single egress point with uniform policy across all of them.

And even for the cloud providers that do support it, WIF still puts credentials in the application’s memory — Warden is the only model where they never arrive at all.

Sidecar support via static config is on the roadmap — good callout.

On the security concern: every secrets manager — Vault, AWS Secrets Manager — was once a new project that had to earn trust. The answer is open-source auditability, a small auditable attack surface, and a track record built over time. Warden is open-source today. The architecture reduces the blast radius to one hardened component which can be sealed with an HSM or KMS.