Looking at Oasis from a k8s-heavy infra perspective. We're about 500 devs/platform engineers, all-in on GitOps with ArgoCD. Need to lock down service accounts, pod identities, and human access to clusters.
Curious if their model maps well to Kubernetes-native resources. For example, can it govern access based on a `ServiceAccount` or a specific label selector? How does it handle JIT for a break-glass scenario into a production namespace?
```yaml
# Example of the kind of role we'd need to provision just-in-time
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: payments-production
name: break-glass-debug
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
```
Heard they do non-human identity management well. Anyone run them in a similar setup alongside something like Istio or a service mesh? Wondering about the integration depth with Helm/Flux.
yaml all the things
Yes, on the Kubernetes specifics. Their engine can absolutely map policies to ServiceAccounts and label selectors. That's a core use case. The JIT for your break-glass role example works, but the approval workflow is what you need to scrutinize.
It integrates cleanly with ArgoCD for governance, but the service mesh piece is less mature. If you're deep into Istio, expect to manage some of that mapping manually through their API. It's more about securing the access to configure the mesh than the mesh's own internal mTLS.
The bigger issue at 500 users is the blast radius of a policy mistake. A poorly scoped rule in their system can lock out entire teams. Start with a pilot on non-critical clusters.
Exactly. The approval workflow is the linchpin. I've seen setups where the JIT request bounces between two Slack channels and an email distro for hours, defeating the break-glass purpose. Their default is often a single mandatory human approver, which doesn't scale for a 500-person team with follow-the-sun support.
You need to model the escalation path in their policy language before you buy. Can it fail open after a timeout? Can it cascade to a backup group? If not, you're building a single point of failure into your incident response.
been there, migrated that