DevOps.com опубликовал разбор о том, почему ручная проверка планов перестала работать. По мнению автора, ручная проверка планов инфраструктурных изменений теряет эффективность при росте потока изменений от агентов.
Требование одобрения может остаться в процессе и журнале аудита, но перестать выполнять контрольную функцию, если рецензенты одобряют изменения, чтобы убрать очередь. Автор предлагает проверять соответствие правилам при создании плана и не применять план, который успел устареть.
Для дорогих и трудно обратимых классов ресурсов автор советует по умолчанию запрещать, а остальные изменения одобрять автоматически. Оценку возможного ущерба автор предлагает заменить ограничениями: сроком жизни тестовой инфраструктуры, лимитами бюджета, ограничением типов ресурсов и размещением в непроизводственных учетных записях.
Проверку того, соответствует ли изменение запросу, автор оставляет людям, потому что система правил не знает исходного требования. Журнал аудита должен создаваться при применении правил и содержать правило, входные данные, решение и время.
Проверка утверждений:
- DevOps.com опубликовал разбор о том, почему ручная проверка планов перестала работать. (подтверждено самой публикацией: доказательство; «Why Plan Review Stopped Working»)
- По мнению автора, ручная проверка планов инфраструктурных изменений теряет эффективность при росте потока изменений от агентов. (подтверждено самой публикацией: доказательство; «Nothing removed plan review. Change volume saturated it.»)
- Требование одобрения может остаться в процессе и журнале аудита, но перестать выполнять контрольную функцию, если рецензенты одобряют изменения, чтобы убрать очередь. (подтверждено самой публикацией: доказательство; «The approval requirement is still declared in the workflow file, still blocking the merge, still writing an audit event, and no longer doing its job.»)
- Автор предлагает проверять соответствие правилам при создании плана и не применять план, который успел устареть. (подтверждено самой публикацией: доказательство; «Evaluate the change against policy when the plan is generated, and reject at apply any plan whose state has since moved, so the replan is evaluated again.»)
- Для дорогих и трудно обратимых классов ресурсов автор советует по умолчанию запрещать, а остальные изменения одобрять автоматически. (подтверждено самой публикацией: доказательство; «Configure deny by default for the resource classes where errors are expensive and hard to reverse, which means identity and access management (IAM), networking, and data resources. Auto-approve the remainder.»)
- Оценку возможного ущерба автор предлагает заменить ограничениями: сроком жизни тестовой инфраструктуры, лимитами бюджета, ограничением типов ресурсов и размещением в непроизводственных учетных записях. (подтверждено самой публикацией: доказательство; «Replace the estimate with a constraint. Assign experimental infrastructure a time to live (TTL) and destroy it on expiry. Apply budget caps. Restrict which resource types can be created. Place it in non-production accounts with no path to production data.»)
- Проверку того, соответствует ли изменение запросу, автор оставляет людям, потому что система правил не знает исходного требования. (подтверждено самой публикацией: доказательство; «Intent verification is the function a policy engine cannot perform. Policy evaluates resource types, fields, and values. It has no access to the requirement the change was written to satisfy.»)
- Журнал аудита должен создаваться при применении правил и содержать правило, входные данные, решение и время. (подтверждено самой публикацией: доказательство; «A policy evaluation that emits its own record produces an audit trail with content in it, naming the rule that ran, the input, the decision, and the time.»)
Публикации:
оценка 62,6 из 100 · тип: разбор