Kubernetes policy anchor: как защитить admission control от удаления

Проблема

API-managed policy появляется только после запуска API server и остается объектом того же control plane, который должна ограничивать. Это создает bootstrap window и self-protection gap: достаточно привилегированный субъект может изменить или удалить защитный объект.

Kubernetes v1.36 добавляет alpha manifest-based admission control. Policies загружаются из локального каталога до обработки запросов и могут защищать API-managed admission resources от изменения. Это сильная идея, но ее внедрение само становится частью control-plane engineering.

Решение: policy anchor плюс fleet verification

Static policy directory должен управляться как Tier-0 configuration: read-only mount, signed change, separate approval, tested rollback и одинаковый digest на каждом API server. Метрика configuration hash превращается в drift detector для control plane.

Поскольку функция alpha, сначала нужны staging cluster, upgrade test, invalid-manifest test и documented recovery path. Production adoption без этого способна превратить fail-closed в self-inflicted outage.

Что проверить руками

• Все API server используют один desired policy digest и контролируемый rollout.
• Каталог policy недоступен для изменения через Kubernetes API и обычные workload identities.
• Invalid startup policy действительно блокирует запуск и поднимает понятный incident signal.
• Recovery procedure работает без обхода через тот же заблокированный API.
• Audit log различает static и API-managed admission decisions.

Безопасный пример: drift check

Псевдокод сравнивает ожидаемый digest с метриками всех control-plane узлов. Он не изменяет кластер.

EXPECTED = load_signed_desired_state("admission-policy.json")["sha256"]
observed = query_control_plane_metric("apiserver_admission_config_hash")

for node, digests in observed.items():
    if digests != {EXPECTED}:
        raise PolicyDrift(
            node=node,
            expected=EXPECTED,
            observed=sorted(digests),
        )

print("policy anchor consistent across all API servers")

Типичные ошибки

• Включать alpha feature сразу на production control plane без recovery exercise.
• Синхронизировать файлы без проверки digest и состояния каждого API server.
• Хранить static policy на writable volume, доступном workload или generic automation.
• Считать наличие deny policy доказательством, не проверяя реальный admission decision.

Evidence и критерий ретеста

• Signed desired-state manifest и digest всех API server сохранены в assessment evidence.
• Staging test подтверждает fail-closed, atomic reload и out-of-band recovery.
• Разрешенная попытка изменить protected policy отклоняется и видна в audit trail.