Mikhail [azalio] Petrov
GKE metadata-proxy: элегантный способ получения JWT без дыр в RBAC
GKE metadata-proxy: элегантный способ получения JWT без дыр в RBAC Недавно беседовали с коллегой про Workload Identity Federation в GKE и выяснилось, что не все знают, как metadata-proxy получает JWT токен от имени пода. А вы знаете, как это работает под капотом? Что такое WIF? Простая идея: токен пода обменивается на cloud token для доступа к облачным API. Никаких статических ключей! Два подхода к безопасности: ❌ Небезопасный подход (как в эмуляторе): rules: - apiGroups: [""] resources: [serviceaccounts/token] verbs: [create] Критическая уязвимость! Такая роль позволяет получить JWT токен от ЛЮБОГО ServiceAccount в кластере! ✅ Элегантное решение GKE: 1...
😠 Агент-лимитер “слепнет” после появления новых PV? Раз и навсегда разбираемся с `mountPropagation` в Kubernetes
😠 Агент-лимитер “слепнет” после появления новых PV? Раз и навсегда разбираемся с `mountPropagation` в Kubernetes! Недавно писал I/O-лимитер для LVM-томов: агент читает маунты подов, чтобы вычислить MAJOR:MINOR для добавления в io.max, и всё ок… пока на узел не приедет новый Pod. Его маунта агент уже не видит. Перезапуск помогает, но это же костыль! Почему так происходит * Каждый контейнер стартует в своём *privаte* mount-namespace -> изменения на хосте туда не пролетают. * В Kubernetes это равно mountPropagation: None. Как починить? Параметр mountPropagation у volumeMounts имеет 3 режима: * None - полная изоляция (`rprivate`), дефолт...
