Деплой и инфра
Secrets at deploy: тест с выбором ответа
Суть Синтез по всему юниту secrets-at-deploy в формате выбора: гигиена образа, base64 против шифрования, etcd at rest, способ инъекции, sealed secrets и rotation.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает реальное решение на этапе деплоя — это не определение для заучивания, а модель угроз, которую нужно продумать под аудитом.
Цель
Убедитесь, что можете связать гигиену образа, ловушку base64, шифрование etcd, способ инъекции, sealed secrets и rotation в единую позицию: где secret попадает внутрь и где утекает.
Викторина
Completed
Dockerfile задаёт ENV API_KEY=sk-live-abc в раннем слое, затем поздний слой выполняет `unset API_KEY`. Безопасен ли ключ в запушенном образе?
Heads-up Состояние env в рантайме и слои на диске — разные вещи. Build-time ENV вшит в слой, который остаётся в реестре независимо от того, что делает поздний слой в рантайме.
Heads-up Автоматического squash нет, и даже squash-образ утечёт, если вытянуть build-кэш или промежуточные слои. Правило: вообще не класть secret в сборку.
Heads-up Любой с доступом на чтение реестра вытягивает и воспроизводит слои. Приватные реестры всё равно утекают на каждый аккаунт, CI-джоб и закешировавший узел, который может вытянуть образ.
Викторина
Completed
Коллега уверяет, что кластер безопасен, потому что каждое значение Kubernetes Secret закодировано в base64. В чём точная поправка?
Heads-up base64 полностью обратим, это не хеш. Любой, у кого есть закодированная строка, тривиально получает плейнтекст обратно.
Heads-up Кодирование и шифрование — разные вещи. Значение base64 по умолчанию лежит в etcd незашифрованным; никакой ключ кластера не применяется, пока не настроишь encryption at rest.
Heads-up base64 не останавливает ничего. Нет ключа и нет work factor; разворот — одна команда, так что конфиденциальности ноль даже против случайного доступа.
Викторина
Completed
Вы настроили EncryptionConfiguration, чтобы API-сервер шифровал Secrets at rest в etcd. Аудитор всё равно находит старый Secret в плейнтексте в бэкапе etcd. Почему и что упущено?
Heads-up Новые Secrets, записанные после изменения, зашифрованы; пробел именно в уже существующих значениях, которые не трогаются, пока их не перепишут.
Heads-up Encryption at rest означает, что API-сервер шифрует перед записью в etcd, поэтому бэкап зашифрованных Secrets — это шифртекст. Плейнтекст здесь — остаток непреобразованных данных.
Heads-up base64 — это лишь кодировка поля value; оно не взаимодействует со слоем encryption at rest в etcd и не перекрывает его.
Викторина
Completed
Error-трекер показывает живой пароль БД в плейнтексте внутри стектрейса. Secret инъецировался как переменная окружения. Корневая причина и структурное исправление?
Heads-up Захват состояния процесса при ошибке — это задуманное поведение SDK, а не баг. Пока secret живёт в окружении, любой захват crash-state может его утечь.
Heads-up Длина ни при чём. Утечка из-за того, что env глобален, наследуется и сбрасывается при крахе — файл, который читаешь один раз и не реэкспортируешь, избегает всех трёх.
Heads-up Deny-list — хрупкая заплатка, пропускающая переименованные или вложенные ключи. Структурное исправление — вообще убрать secret из окружения через file mount.
Викторина
Completed
Небольшой GitOps-команде нужно закоммитить секретную конфигурацию в приватный репозиторий, чтобы Argo CD её применил, при минимуме внешних зависимостей. Какой подход верный и почему его действительно безопасно коммитить?
Heads-up base64 — это кодирование, не шифрование. Любой с доступом на чтение репозитория выполняет base64 -d и читает плейнтекст; форки и история делают утечку необратимой. Это ровно та ловушка, с которой начинается юнит.
Heads-up ConfigMap по замыслу в плейнтексте и предназначен для несекретной конфигурации. Коммитить туда секреты строго хуже base64 Secret — нет кодирования, шифрования и разделения доступа.
Heads-up ESO отлично работает на масштабе, но добавляет внешний менеджер, который команда не просила, и не кладёт самодостаточный коммитируемый артефакт в репозиторий. Тяжелее, чем нужно здесь.
Викторина
Completed
Безопасность требует rotation секретов каждые 30 дней и хочет, чтобы украденный credential быстро становился бесполезным. Вы на Kubernetes, доступен Vault. Какая связка лучше всего достигает обеих целей?
Heads-up Env-переменные заморожены на старте контейнера, поэтому rotation требует рестарта, а статический 30-дневный credential при краже валиден все 30 дней. Ни одна цель толком не достигнута.
Heads-up Более частая rotation статического долгоживущего секрета сужает окно, но украденный credential всё равно валиден до следующей rotation. Dynamic короткоживущие creds устраняют долгоживущий secret полностью.
Heads-up Encryption at rest защищает хранимые Secrets от кражи etcd; оно ничего не делает с частотой rotation или ограничением времени жизни утёкшего credential.
Итог
Сквозная линия юнита — один путь решений: secret попадает внутрь на деплое или в рантайме (никогда в образе), его нужно по-настоящему шифровать, а не кодировать в base64, для etcd нужно настроить encryption at rest и переписать существующие Secrets, file mounts превосходят env-переменные по поверхности утечки и rotation на месте, Sealed Secrets дают коммитируемый GitOps-артефакт, а dynamic короткоживущие credentials делают украденный secret бесполезным до истечения срока. Каждый неверный ответ здесь — реальный инцидент, который кто-то уже пережил.