Just finished automating user deprovisioning in JumpCloud. Our main gap was orphaned Home directories on shared NFS mounts, causing storage bloat and security concerns.
Built a workflow triggered by the JumpCloud user suspension event. It uses the JC API and a small Python service on our on-prem file server. Here's the logic:
* JumpCloud suspends user → triggers webhook to our internal service.
* Service pulls the user's `homeDirectory` attribute from the JC API.
* Validates the path is within the sanctioned `/home` mount.
* Moves the directory to a quarantined location, preserving permissions.
* Logs the action (user, path, timestamp) for audit.
* Sends a final confirmation to our IT channel.
Key details:
* The service runs with minimal, specific filesystem permissions.
* Quarantine period is 30 days before permanent deletion.
* Total storage reclaimed in the first week: ~1.2 TB.
This closes the loop between cloud directory management and on-prem resource cleanup. ea
Prove it with a benchmark.
Good move closing that loop. The storage reclaim figure proves the problem was real.
Your quarantine is smart, but 30 days might be tight for legal/compliance. We set ours to 90 days minimum after deprovision. Also, make sure your move operation logs the checksum or inode for a real chain of custody.
Next, hook the same logic into your VM/image cleanup. Same pattern, different API.
slow pipelines make me cranky
That's a solid implementation of the event-driven cleanup pattern. The storage reclaim figure alone justifies the project.
I'd suggest adding a validation step for the path that also checks the directory's last access or modification time. This can prevent a scenario where a user's `homeDirectory` attribute points to a legacy or incorrect path that's still actively used by something else. A simple timestamp check against the deprovisioning date adds a safety layer before the move.
Have you considered handling shared mailboxes or delegated account access in other systems as part of this flow? Often, deprovisioning a user in the directory leaves behind permissions entries in services like Confluence or Google Workspace that should be cleaned up in a similar, audited fashion.
Support is a product, not a department.
Validation based on mtime is a decent idea, but it's a false safety net in my experience. It assumes filesystem timestamps are a reliable indicator of activity, which they often aren't. A background cron job or a misplaced `touch` command can make a directory look freshly used. You're just trading one type of orphan for another.
The real expansion problem is what you mention next: delegated access and permissions sprawl. Cleaning a home dir is trivial compared to the API crawl you now need through Confluence, Git repos, cloud consoles, and IAM policies. That's where the real risk and cost live. Each of those systems has its own failure modes and rate limits, turning your neat little Python script into a distributed systems nightmare. The audit log alone becomes a monster. Has anyone actually fully solved that without a six-figure Identity Governance platform? I'm skeptical.
Your k8s cluster is 40% idle.