kb/security
Sensitive-значения в variable/output/local, статический анализ конфигов через Checkov и Trivy/tfsec, безопасное хранение секретов (AWS Secrets Manager, Vault, OIDC вместо access keys), и почему `sensitive = true`, про логи, а не про шифрование.
Checkov, Python-сканер от Prisma Cloud, проверяет `.tf` и `plan.json` против ~2000 встроенных правил (CKV_AWS_*, CKV_K8S_*, etc.). Запускается на HCL до plan'а (быстрее) или на JSON-plan (богаче, видит вычисленные значения). Suppressions делаются комментарием в HCL или в файле конфигурации; baseline-файл фиксирует найденные issues как «приемлемые на сейчас», чтобы новые сразу ломали CI.
`sensitive = true` у variable/output/local прячет значение от CLI-вывода и логов. В state и .tfstate.backup значение **открытое**. Это redaction, не encryption. Реально секретное, храни в Secrets Manager или Vault, читай через data-source, плана не сохраняй в артефактах. `nonsensitive()` нужен в редких случаях когда sensitive-флаг каскадируется и мешает.
tfsec, оригинальный security-сканер от Aqua, написан на Go, быстрый. С 2023 года слит в Trivy, у того теперь модуль `trivy config` для IaC, та же база правил (AVD-* идентификаторы). Альтернатива Checkov: меньше правил, но быстрее, бинарь без зависимостей. В CI обычно: либо Trivy/tfsec, либо Checkov, не оба.
State содержит всё что прошло через apply, пароли, ключи, токены в открытом виде. Решения: хранить секреты в Secrets Manager / Vault / KMS, читать через data-source, шифровать backend (S3 SSE-KMS), OIDC вместо access-keys для CI. «sensitive=true», про логи, не про шифрование.