Directory, Identity and Secrets Cluster Services
One directory that can answer "who has access to what", replicated across sites, with certificate and secret lifecycles that do not depend on a calendar reminder.
What this usually looks like
Identity is the dependency everything else authenticates against, and it is usually the service with the fewest replicas and the oldest design.
- Local accounts on servers mean nobody can list who has administrative access to what.
- A single directory instance serves three sites, and a reboot is a company-wide login outage.
- Certificates are renewed manually, and one always expires on a Friday evening.
- Application secrets are stored in configuration files and copied between environments by hand.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Authentication and authorisation inventory across servers, apps and clusters
- Directory replication and CA health review, including renewal windows
- Secret sprawl assessment: where credentials live and who can read them
- Break-glass and recovery review — can you still log in if the directory is down?
Build
One-off delivery: design, code, hardening, handover
- Multi-replica directory across failure domains with automated CA renewal
- SSO for internal applications with group-based authorisation, not per-app user lists
- Vault or Consul as the secrets system, with policies, audit logging and unsealing design
- Workload identity for Kubernetes and CI, replacing stored long-lived credentials
- Host enrolment automated, with a reversible batch rollout
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Replication lag and directory health monitoring with alerting
- Certificate lifecycle owned end to end, including CA and intermediate rotation
- Access review support — evidence of who could do what, on request
- Secret rotation on schedule for system and service accounts
- Directory failover and restore drill each quarter
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Directory services
- FreeIPA
- 389 Directory Server
- OpenLDAP + syncrepl
- Active Directory DS (integration)
- MIT Kerberos KDC
SSO & federation
- Keycloak
- OIDC
- SAML 2.0
- LDAP federation
- SCIM provisioning
Secrets management
- HashiCorp Vault
- Consul (KV + service mesh CA)
- External Secrets Operator
- SOPS
- Sealed Secrets
PKI & workload identity
- step-ca
- cert-manager
- SPIRE
- short-lived certificates
- HSM-backed roots
Access & privilege
- SSSD
- sudo policy in the directory
- HBAC rules
- Teleport / bastion
- session recording
Host integration
- Ansible enrolment roles
- ipa-client
- sshd certificate auth
- PAM stack review
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Every host authenticates against the directory; zero local administrative accounts remain.
- Losing one directory replica causes no user-visible impact, proven by taking one out of service.
- Certificate expiry is a monitored event with automated renewal, not a calendar entry.
- Every administrative access path is attributable to a named identity, with an audit trail.
- Break-glass access exists, is documented, is tested, and is stored outside the directory it protects.
What we would build, and where the weak point is
The secrets store is the real single point of failure here — which is exactly why its unsealing design and its backup strategy matter more than its clustering. A three-node Vault cluster that cannot be unsealed after a power event is a single node with extra votes.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Human resources and joiner-mover-leaver process ownership
We automate the technical side of provisioning; the decision of who joins and leaves stays with your HR process.
- Out of scope
Endpoint device management and MDM
Laptops and phones are a different discipline with different tooling. We integrate with your MDM rather than replacing it.
- Requires partner
Microsoft 365 tenant administration
We integrate with it and can configure hybrid identity. We do not act as your Microsoft administrator of record.
- Out of scope
Application-level authorisation logic
We deliver verified identity and groups. What your application does with them is your product decision.
What it looked like last time
An engineering group running 320 Linux servers on local accounts with hand-distributed SSH keys: rebuilt as a four-replica FreeIPA deployment across three sites, hosts enrolled in reversible batches with Ansible, sudo and host-based access control centralised — and an authoritative answer, for the first time, to "who has root where".
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the identity engineer about your directory, identity & secrets
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a identity engineer: botonwa@gmail.com · +86 130 5181 3099