SHEET FIG.4 — /en/work/zero-trust-automation
CASE STUDY § 01-4
Zero trust platform operations automation
identify → propose → build
APPROACH
idempotent automation
PROPERTY
zero trust platform
DOMAIN
Challenge
A zero trust platform has many components, and depending on manual operation tends to cause configuration drift and lower reproducibility. At enterprise scale, that effort turns directly into operational risk.
On site, the recurring operational work and environment setup were each done by hand. These needed to be turned into a form that could be repeated safely.
Design decisions
- Started by identifying the operational issues and proposing the targets and scope for automation (involvement from before the requirements were given)
- Designed the automation tool on the premise of idempotency, so that state converges to a single result no matter how many times the same operation runs
- Implemented it in Go, and set up CI/CD by combining GitHub Actions and CodeBuild
- Included Elasticsearch environment setup in the scope of automation
Hover, focus, or tap a node to see the design rationale for each element.
- Operational issues — identified the repeated operational work on the zero trust platform. Proposed the targets for automation.
- Automation tool (Go) — designed and implemented on the premise of idempotency. State converges to a single result no matter how many times it runs.
- CI/CD — build and deployment set up with GitHub Actions and CodeBuild.
- Elasticsearch — environment setup included in the scope of automation.
Approach
- Worked in the order identify issues → propose → design → implement, taking part in choosing the target rather than implementing a given spec
- Guaranteed idempotency in the automation so it could sit in operations that assume repeated runs