> So Strix enumerated hosts, looked through certificate logs, mapped the full surface.
If there is anything that you should do while setting up infrastructure... it is getting rid of single-host SSL certificates. If you're on Amazon... just let it issue wildcard certificates and place an ALB in front of hosts that terminates the SSL connection. The very second a subdomain appears in any of the CT logs directly, you've lost, it will get hammered.
And keep your public and private Git, Docker, npm and whatnot registries separate infrastructure, with the private stuff only reachable from within the corporate network, preferably just servers. Too many a company got hacked and lost significant data because of someone exploiting a GitLab RCE on an instance that hosted both private and intentionally-public repositories. (Yes, I have been there.)
> It is their GitOps: the repository contains the desired state of the clusters, and it applies that state to the infrastructure.
That's another thing I frankly do not get why people are still doing it.
It's fine to have a Git pipeline do a lint, even a terraform plan using a read-only token (although that token needs access to the statefile aka s3 bucket... and there will be relevant secrets there). But, IMHO, a terraform apply should always, always be run on a machine of a sysadmin manually doing the apply. A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens. But a Git pipeline where there is a cloud provider token with full admin permissions? That is one Gitlab RCE patch or Github issue away from being compromised.
Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
GitOps offers more benefits than downsides if configured correctly. It is more secure and scalable and auditable than manual apply from workstations. However it should be using short lived (e.g. workload identity), minimum privilege credentials, not broad admin level grants.
Also IaC is not just about terraform. Much of the action is usually in the kubernetes manifests via ArgoCD, flux, and etc. Good luck to anyone keeping track of all those manual helm installs, and then rebuilding or upgrading a cluster without these tools.
> A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens.
You can do this too (and better) with a repo: OIDC/Workload identity trust relationship between github and aws for short lived tokens + a github environment setup that requires manual approval. Bonus: It also gives you an audit trail with a github action log as opposed to a sysadmin running something on a laptop.
The problem here was mostly that they (for some reason) happened to use (and leak) a PAT.
This is the way. And the benefit that still makes it more worth it today, is the fact that you can have truly self-service and peer reviewed infra provisioning and don't depend on a single sys admin or several of them colliding on their machines.
The audit log for the sysadmin is in Cloudtrail, so nothing is lost there.
> Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
If it is terraform, then typically it's split up into multiple "root modules" which get planned and applied separately, even though it's all in one repo.