OPA и SPIFFE — два новых проекта в CNCF для безопасности облачных приложений

В конце марта у фонда CNCF, помогающего развивать Open Source-проекты для облачных (cloud native) приложений, случилось двойное пополнение: в «песочницу» были ^[1] добавлены ^[2] OPA (Open Policy Agent) и SPIFFE (Secure Production Identity Framework For Everyone), которых роднит тема безопасности. Для чего же они могут пригодится?

Open Policy Agent

Open Policy Agent ^[3] (GitHub ^[4]) — написанный на языке Go движок, предлагающий унифицированный способ использования политик, которые учитывают контекст и работают по всему стеку инфраструктуры, применяемой для облачных приложений.

Инициатива по созданию Open Policy Agent исходит от компании Netflix. Как рассказывали ^[5] её представители на 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, получилась следующей:

А в более подробном представлении архитектура системы, использующей OPA, выглядит так (слайды взяты из этой презентации ^[6]):

Политики в OPA пишутся на высокоуровневом декларативном языке (он называется Rego) и загружаются через файловую систему или API. Сервисы передают ответственность за принятие решение по политикам запросом в движок Open Policy Agent, который просматривает политики и дополнительные данные, принимает решение по запросу и возвращает его клиенту. Интеграция приложения с OPA может быть реализована разными методами: sidecar-контейнер, демон на уровне хоста, библиотека. По уверениям авторов, для простых политик средняя задержка составляет около 0,2 мс.

Простейшая иллюстрация использования API от Open Policy Agent представлена в GitHub проекта ^[4]:

Пользователям можно просматривать свою зарплату и зарплату сотрудников, находящихся в их подчинении:

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, равно как и о работе с этим движком, описаны в документации проекта ^[7]. Там же можно найти примеры интеграции с Admission Controllers в Kubernetes ^[8] (требуется версия K8s 1.9+ и включённый ValidatingAdmissionWebhook), с Docker ^[9] (требуется Docker Engine 1.11+) и с SSH ^[10] (используется плагин к Linux-PAM).

Secure Production Identity Framework For Everyone

Авторы SPIFFE ^[11] (GitHub ^[12]) иначе подошли к проблеме аутентификации — они предлагают веб-сервисам фреймворк и набор стандартов, которые упраздняют саму потребность в аутентификации и авторизации на уровне приложений, а также в сложных конфигурациях списков доступа на уровне сети.

Основу SPIFFE составляют три компонента:

1. SPIFFE ID. Стандарт, определяющий, как сервисы идентифицируют друг друга между собой. Это структурированные строки (представляются как URI — например, spiffe://trust-domain/path), выступающие в роли названия для сущности.
2. SPIFFE Verifiable Identity Document (SVID). Стандарт для преобразования SPIFFE IDs в верифицируемый криптографически документ (такой документ и называется SVID). Спецификация определена в The SPIFFE Identity and Verifiable Identity Document ^[13]. Кроме того, отдельно существует спецификация для X.509 SVID ^[14].
3. Workload API. Спецификация API для выдачи и получения SVIDs. Как правило, методы API доступны локально (например, через сокет домена Unix) и не требуют аутентификации из рабочей нагрузки. Подлинность обращающегося к Workload API может быть проверена сторонним методом (например, по предоставляемым операционной системой свойствам процесса, который обращается к сокету). Кроме того, Workload API предоставляет сертификаты (CA bundles). Работа над спецификацией ещё ведётся (доступен прототип ^[15]).

Архитектура окружений, использующих предлагаемый в SPIFFE подход, представляется так:

Помимо собственно спецификаций, а также связанных с ними примеров и другой документации, хранящихся в основном репозитории ^[16] проекта, авторы подготовили эталонную реализацию своих базовых компонентов — SPIRE ^[17] (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 можно почитать здесь ^[18].

Кроме того, у проекта есть библиотеки на Go (go-spiffe ^[19]) и C/C++ (C-SPIFFE ^[20]).

Работа над SPIFFE ведётся в рамках групп SIG (Special Interest Groups) по аналогии с Kubernetes. Среди возглавляющих их специалистов — сотрудники компаний Scytale (инициаторы и главные авторы проекта), Google, Pensando и Blend. В частности, функционируют группы, занимающиеся интеграцией SPIFFE с Kubernetes ^[21], gRPC ^[22] и AWS ^[23].

На сайте SPIFFE заявляется, что проект «находится на ранних этапах реализации и пока не готов для использования в production».

P.S.

Читайте также в нашем блоге:

• «Путеводитель CNCF по решениям Open Source (и не только) для cloud native ^[24]»;
• «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017 ^[25]»;
• «Rook — «самообслуживаемое» хранилище данных для Kubernetes ^[26]»;
• «CoreDNS — DNS-сервер для мира cloud native и Service Discovery для Kubernetes ^[27]»;
• «Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров ^[28]»;
• «Инфраструктура с Kubernetes как доступная услуга ^[29]».

Автор: shurup

Источник ^[30]