Агент открытой политики (OPA) для Kubernetes

Как бы мы ни ненавидели слово «стандарт», в конце концов, мы должны иметь стандарт для сред. Независимо от того, как мы развертываем облачную инфраструктуру или как получаем уведомления о сбоях, стандарты очень важны. Стандарты, касающиеся развертывания и управления компонентами в наших средах, не менее, если не более, важны.

В этой статье блога вы узнаете о том, что такое OPA и как он связан с Kubernetes.

Что такое OPA?

Короткий ответ: это стандартизированный способ реализации политик для вашей среды (кто имеет доступ к чему, что может быть развернуто, где оно может быть развернуто и т.д.).

Длинный ответ: у вас есть способ управления каждым отдельным уровнем вашей среды с тонким контролем над тем, как все части вашей среды взаимодействуют друг с другом. Если у вас есть среда Kubernetes, вы можете управлять всем: от того, кто имеет доступ к каким Pods, до того, как Pods развертываются с помощью Kubernetes Manifest и инжектирования sidecars в Pods.

Для реализации этих политик используется так называемый Rego, который представляет собой язык OPA (считайте, что это язык программирования). Rego позволяет вам определить точную политику, которая вам нужна в вашей среде Kubernetes, вплоть до самого маленького форм-фактора, например, Label. Поскольку все политики представляют собой код, это позволяет вам работать с вашей командой для сотрудничества, а не иметь решение «наведи и щелкни», над которым вы не можете работать.

Например, приведенный ниже код проверяет, чтобы метка mylastname в Kubernetes Manifest начиналась с Levan. Если это не так, вы получите сообщение об ошибке mylastname label должен начинаться с Levan.

package kubernetes.validating.label

deny[msg] {
    value := input.request.object.metadata.labels.mylastname

    not startswith(value, "levan")

    msg := sprintf("mylastname label must start with `Levan`; found `%v`", [value])
}

Вы можете использовать OPA для применения политик:

• Kubernetes
• Микросервисы
• CICD

и многого другого. OPA доступен практически для любой облачной среды. Вы можете ознакомиться со всеми различными экосистемами здесь, а если вы не можете найти подходящую, вы можете создать ее для вашего случая использования.

Как она вписывается в Kubernetes?

На самом высоком уровне Kubernetes работает как API. Это способ управления инфраструктурой и сервисами через API. Без API Kubernetes не существовало бы Kubernetes.

На втором и более высоком уровне находятся контроллеры. Контроллеры смотрят на то, что вы развернули в Kubernetes, например, на Pods, и подтверждают, что текущее состояние соответствует желаемому. Если вы знакомы с Terraform, представьте его как файл TFSTATE (контроллеры не являются файлами, это просто аналогия). Файл TFSTATE предназначен для подтверждения того, что когда вы развертываете инфраструктуру, она развертывается в желаемом состоянии. Контроллеры Kubernetes проверяют, что Pods (и другие компоненты, Pods — это просто пример) развернуты в нужном состоянии.

OPA Gatekeeper (или иногда называемый OPA Admission Controller), который является проектом, обеспечивающим интеграцию между Kubernetes и OPA, подобен контроллерам, которые были упомянуты выше для Pods. Он подтверждает, что текущее состояние является желаемым. Если погрузиться немного глубже, то Kubernetes Admission Controller обеспечивает соблюдение политик для операций CRUD в вашем кластере Kubernetes. Например, допустим, вы хотите ввести квоты/лимиты ресурсов для подсистем в вашей организации. Затем инженер создает Kubernetes Manifest без ограничений ресурсов для развертываемых им Pods. Если OPA увидит, что инженер пытается развернуть Kubernetes Manifest с помощью чего-то вроде kubectl create -f или kubectl apply -f, Kubernetes Admission Controller заблокирует его развертывание.

Другие части головоломки

Декларативные языки и платформы — это то, на что сегодня ориентируются многие организации. Причина в том, что существует большая разница между тем, как архитектурировать и планировать декларативные рабочие нагрузки и императивные рабочие нагрузки.

Декларативный == сказать мне, что делать, а не как это делать

Императивный == сказать мне, что и как сделать.

Есть несколько причин, по которым инженеры переходят на OPA, и одна из них — тот факт, что OPA и Kubernetes являются декларативными. Rego является декларативным, поэтому вы пишете политики таким образом, чтобы сообщить OPA, что вы хотите, но не как это сделать. В Kubernetes вы пишете файлы YAML, которые сообщают Kubernetes, что вы хотите, но не как это сделать. Поскольку и OPA, и Kubernetes являются декларативными, вы можете строить архитектуру обоих решений одинаково.

Еще одна важная причина заключается в том, что Rego похож на Go (golang), а многие инженеры, работающие в Kubernetes, используют Go, поскольку Kubernetes был построен с использованием Go, а это один из самых лаконичных облачных языков.

Развертывание OPA для Kubernetes

Теперь, когда вы знаете, что такое OPA и почему он важен в Kubernetes, давайте узнаем, как развернуть его на кластере Kubernetes.

1. Создайте новое пространство имен Kubernetes для развертывания OPA.

kubectl create namespace opa

1. Создайте учетные данные TLS для OPA. Связь между Kubernetes и OPA должна быть безопасным соединением с использованием TLS.

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -days 100000 -out ca.crt -subj "/CN=admission_ca"

1. Сгенерируйте ключ и сертификат TLS

cat >server.conf <<EOF
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
prompt = no
[req_distinguished_name]
CN = opa.opa.svc
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = opa.opa.svc
EOF

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -config server.conf
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 100000 -extensions v3_req -extfile server.conf

1. Создайте секрет Kubernetes для хранения учетных данных TLS

kubectl create secret tls opa-server --cert=server.crt --key=server.key --namespace opa

1. Разверните OPA как Admission Controller. Поскольку это огромный файл YAML, вы можете найти конфигурацию на GitHub URL здесь. Он создает следующее для того, чтобы OPA имел доступ к кластеру Kubernetes:
2. ClusterRoleBinding
3. Роль
4. RoleBinding
5. Сервис
6. Развертывание

Вы можете запустить kubectl apply -f admission-controller.yaml, когда возьмете код из URL выше с GitHub.

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

kubectl get all -n opa

Поздравляем! Вы успешно развернули контроллер допуска.