![](https://habrastorage.org/webt/qq/xu/x7/qqxux7irmwa0spowyjcjnh_0ke4.png)
В конце марта у фонда CNCF, помогающего развивать Open Source-проекты для облачных (cloud native) приложений, случилось двойное пополнение: в «песочницу» были добавлены OPA (Open Policy Agent) и SPIFFE (Secure Production Identity Framework For Everyone), которых роднит тема безопасности. Для чего же они могут пригодится?
Open Policy Agent
Open Policy Agent (GitHub) — написанный на языке Go движок, предлагающий унифицированный способ использования политик, которые учитывают контекст и работают по всему стеку инфраструктуры, применяемой для облачных приложений.
![](https://habrastorage.org/webt/cv/sc/d1/cvscd1xphm5vgwg0xf4xkjcotek.png)
Инициатива по созданию Open Policy Agent исходит от компании Netflix. Как рассказывали её представители на CloudNativeCon US 2017, этот проект позволил решить проблему авторизации в масштабах крупного облачного окружения. Если вкратце, то инженеры компании хотели обеспечить стандартизированную (и простую) возможность определять и принудительно исполнять правила следующего вида: Субъект (identity, I) может/не может выполнять Операцию (operation, O) на Ресурсе (resource, R) — во всех возможных комбинациях во всей имеющейся экосистеме.
При этом, как легко догадаться, экосистема Netflix весьма разнообразна: в ней не один тип ресурсов (REST-интерфейсы, gRPC-методы, SSH, Kafka topics и т.п.), не один тип субъектов, а также множество используемых протоколов (HTTP/HTTPS, gRPC, свои бинарные), языков программирования (Java, Node.js, Python, Ruby)… Наконец, критичное требование ко всей этой системе — минимальная задержка: например, один узел кластера Kafka обрабатывает тысячи запросов в секунду, поэтому о прослойке, требующей для авторизации более 1 миллисекунды, и речи быть не могло.
Общая схема решения, к которому пришли в Netflix, получилась следующей:
![](https://habrastorage.org/webt/r8/ws/xk/r8wsxkxyz3bhp-75zw6vvmdupz8.png)
А в более подробном представлении архитектура системы, использующей OPA, выглядит так (слайды взяты из этой презентации):
![](https://habrastorage.org/webt/9w/xe/2r/9wxe2rgoegphkczomlqqyvaib3m.png)
![](https://habrastorage.org/webt/zt/dk/i5/ztdki5quhuh-oxnz77kmlmarnoc.png)
Политики в OPA пишутся на высокоуровневом декларативном языке (он называется Rego) и загружаются через файловую систему или API. Сервисы передают ответственность за принятие решение по политикам запросом в движок Open Policy Agent, который просматривает политики и дополнительные данные, принимает решение по запросу и возвращает его клиенту. Интеграция приложения с OPA может быть реализована разными методами: sidecar-контейнер, демон на уровне хоста, библиотека. По уверениям авторов, для простых политик средняя задержка составляет около 0,2 мс.
Простейшая иллюстрация использования API от Open Policy Agent представлена в GitHub проекта:
Пользователям можно просматривать свою зарплату и зарплату сотрудников, находящихся в их подчинении:
allow {
input.method = "GET"
input.path = ["salary", id]
input.user_id = id
}
allow {
input.method = "GET"
input.path = ["salary", id]
managers = data.management_chain[id]
id = managers[_]
}
Запрос: Может ли Боб посмотреть свою зарплату?
> input = {"method": "GET", "path": ["salary", "bob"], "user_id": "bob"}
> allow
true
Запрос: Цепочка менеджеров для Боба.
> data.management_chain["bob"]
[
"ken",
"janet"
]
Запрос: Может ли Элис посмотреть зарплату Боба?
> input = {"method": "GET", "path": ["salary", "bob"], "user_id": "alice"}
> allow
false
Запрос: Может ли Джанет посмотреть зарплату Боба?
> input = {"method": "GET", "path": ["salary", "bob"], "user_id": "janet"}
> allow
true
Подробности об устройстве OPA, равно как и о работе с этим движком, описаны в документации проекта. Там же можно найти примеры интеграции с Admission Controllers в Kubernetes (требуется версия K8s 1.9+ и включённый
ValidatingAdmissionWebhook
), с Docker (требуется Docker Engine 1.11+) и с SSH (используется плагин к Linux-PAM).Secure Production Identity Framework For Everyone
Авторы SPIFFE (GitHub) иначе подошли к проблеме аутентификации — они предлагают веб-сервисам фреймворк и набор стандартов, которые упраздняют саму потребность в аутентификации и авторизации на уровне приложений, а также в сложных конфигурациях списков доступа на уровне сети.
Основу SPIFFE составляют три компонента:
- SPIFFE ID. Стандарт, определяющий, как сервисы идентифицируют друг друга между собой. Это структурированные строки (представляются как URI — например,
spiffe://trust-domain/path
), выступающие в роли названия для сущности. - SPIFFE Verifiable Identity Document (SVID). Стандарт для преобразования SPIFFE IDs в верифицируемый криптографически документ (такой документ и называется SVID). Спецификация определена в The SPIFFE Identity and Verifiable Identity Document. Кроме того, отдельно существует спецификация для X.509 SVID.
- Workload API. Спецификация API для выдачи и получения SVIDs. Как правило, методы API доступны локально (например, через сокет домена Unix) и не требуют аутентификации из рабочей нагрузки. Подлинность обращающегося к Workload API может быть проверена сторонним методом (например, по предоставляемым операционной системой свойствам процесса, который обращается к сокету). Кроме того, Workload API предоставляет сертификаты (CA bundles). Работа над спецификацией ещё ведётся (доступен прототип).
Архитектура окружений, использующих предлагаемый в SPIFFE подход, представляется так:
![](https://habrastorage.org/webt/5g/c4/ii/5gc4iiugwnwgb0fyxxbi2rswxru.png)
Помимо собственно спецификаций, а также связанных с ними примеров и другой документации, хранящихся в основном репозитории проекта, авторы подготовили эталонную реализацию своих базовых компонентов — SPIRE (the SPIFFE Runtime Environment). Её код написан на языке Go и представляет собой связку из сервера и агента, которые представляют SPIFFE Workload API в действии, т.е. позволяют удостоверять программные системы (workloads, «рабочие нагрузки») и выдавать им SPIFFE IDs и SVIDs.
Workload API от SPIFFE схож с AWS EC2 Instance Metadata API и Google GCE Instance Metadata API в том смысле, что не требует от вызывающей стороны предварительного знания о субъекте или аутентификационного токена. Однако авторы отмечают и важные отличительные особенности своей разработки: 1) она запускается на множестве платформ, б) она позволяет идентифицировать запущенные сервисы не только на уровне процесса, но и на уровне ядра, что позволяет её использовать с планировщиками контейнеров вроде Kubernetes. Для минимизации последствий утечки/компрометации ключа все приватные ключи (и соответствующие сертификаты) живут недолго и подлежат частой (автоматизированной) ротации. Подробнее об архитектуре SPIRE можно почитать здесь.
Кроме того, у проекта есть библиотеки на Go (go-spiffe) и C/C++ (C-SPIFFE).
Работа над SPIFFE ведётся в рамках групп SIG (Special Interest Groups) по аналогии с Kubernetes. Среди возглавляющих их специалистов — сотрудники компаний Scytale (инициаторы и главные авторы проекта), Google, Pensando и Blend. В частности, функционируют группы, занимающиеся интеграцией SPIFFE с Kubernetes, gRPC и AWS.
На сайте SPIFFE заявляется, что проект «находится на ранних этапах реализации и пока не готов для использования в production».
P.S.
Читайте также в нашем блоге:
- «Путеводитель CNCF по решениям Open Source (и не только) для cloud native»;
- «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
- «Rook — «самообслуживаемое» хранилище данных для Kubernetes»;
- «CoreDNS — DNS-сервер для мира cloud native и Service Discovery для Kubernetes»;
- «Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров»;
- «Инфраструктура с Kubernetes как доступная услуга».