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

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

Open Policy Agent

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

Инициатива по созданию 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, получилась следующей:

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

Политики в 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 составляют три компонента:

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

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

Помимо собственно спецификаций, а также связанных с ними примеров и другой документации, хранящихся в основном репозитории проекта, авторы подготовили эталонную реализацию своих базовых компонентов — 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 как доступная услуга».

Автор: shurup

Источник