Six months ago, we made the decision to move off our cobbled-together IAM stack (a mix of open-source tools and custom scripts) and implement Identiq across our Kubernetes and cloud environments. As a mid-market fintech, our requirements were stringent: we needed robust audit trails for compliance (SOC2, ISO27001), seamless integration with our existing OIDC provider, and a way to manage just-in-time (JIT) and break-glass access to our production clusters. I wanted to share a detailed, warts-and-all review of our experience, focusing on the practical, day-to-day operations.
The initial setup was relatively smooth, thanks to their Helm chart. The real test was integrating it with our existing tooling. Here's a snippet of the custom `Values.yaml` we used to wire it into our private OIDC provider and set up the Kubernetes authenticator:
```yaml
identiq:
authenticators:
kubernetes:
enabled: true
clusterName: "prod-us-west-2"
# Pinned to a specific CA bundle from our internal PKI
caBundle: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
identitySources:
- name: "corporate-oidc"
type: oidc
config:
issuerUrl: "https://auth.internal.example.com/realms/fintech"
clientId: "identiq-access-proxy"
# Secret stored in external secrets manager, referenced here
clientSecretRef: "azure-keyvault/identiq-oidc-secret"
```
**What worked exceptionally well:**
* **The Just-in-Time Access Flow:** Creating temporary, scoped `kubeconfig` files for contractors or developers needing to debug production issues has become a one-click operation. The approval workflows tie directly into our Slack channels.
* **Audit Log Clarity:** Every access request, approval, and session is logged with immutable timestamps and user context. This made our last compliance audit significantly less painful.
* **Service Mesh Integration:** We use Istio, and Identiq's sidecar injector for mTLS-based service identity worked without major refactoring. It replaced a custom cert-manager setup we were struggling to maintain.
**Where we hit friction:**
* **The "Break-Glass" Scenario:** While the process exists, during a critical Sev-1 incident where our primary OIDC provider had a blip, we found the break-glass procedure to be more steps than we'd like. We've since documented and rehearsed it, but the initial experience was stressful.
* **Custom Role Mapping:** Translating our existing, somewhat messy RBAC `ClusterRole` definitions into Identiq's policy language had a learning curve. We ended up writing a small conversion script, which I can share if anyone's interested.
* **Cost Complexity:** The per-seat + per-node pricing model can get tricky to predict as you scale pods. We're still working on optimizing our service account usage to keep costs in check.
Overall, the platform is powerful and has given us much-needed control and visibility. It's not a "set and forget" system—it requires ongoing policy tuning and a good understanding of your own access patterns. For teams already deep in Kubernetes looking to seriously mature their IAM posture, it's a strong contender, but be prepared to invest time in the integration details.
kubectl apply -f
yaml is my native language