AccessPolicy

Содержание

Overview Availability Understanding AccessPolicy Что означает «Использовать коннектор»Как работает AccessPolicy Две модели доступа Granting Default Proxy Access Пример Granting Access After Approval Пример Common Configuration Patterns Выбор Connectors для защиты Пример Выбор ServiceAccounts, получающих доступ по умолчанию Пример Status What's Next

Overview

AccessPolicy — это ресурс с областью видимости в пространстве имён, который контролирует, кто может использовать Connectors через Connectors Proxy.

Он определяет три вещи:

какие Connectors охватываются политикой
предоставляется ли доступ через прокси по умолчанию или только после прохождения проверок
какие субъекты охватываются этой моделью доступа

В модели Connectors Approval AccessPolicy — это определение политики, тогда как фактический запрос во время выполнения отслеживается отдельно с помощью AccessRequest.

INFO

Читайте этот документ после Connectors Approval & Permission Gating.

Этот документ сосредоточен на долгосрочном правиле, которое администраторы разрабатывают:

какие Connectors охватываются
кто должен получать доступ через прокси по умолчанию
какие проверки должны пройти, прежде чем будет предоставлен временный доступ через прокси

Он не повторяет полный жизненный цикл одного запроса во время выполнения. Для этого продолжайте с AccessRequest.

INFO

В этой модели использовать коннектор означает использовать путь доступа без секретов коннектора через Connectors Proxy, либо напрямую, либо через Connectors CSI Driver.

AccessPolicy не контролирует доступ к Connectors API. Connectors API использует отдельные разрешения connectors/apis, которые обычно применяются для обнаружения ресурсов в UI или других интеграций на основе API.

Availability

AccessPolicy является частью функционала Connectors Approval.

Перед использованием включите:

enable-connectors-approval
enable-connector-proxy-permissions

Для получения дополнительной информации смотрите Feature Flags.

Understanding AccessPolicy

Что означает «Использовать коннектор»

AccessPolicy сосредоточен на доступе через прокси, а не на чтении объектов Connector или просмотре ресурсов через Connectors API.

Типичные примеры использования коннектора:

workload отправляет запросы на адрес прокси коннектора
Pod монтирует конфигурацию коннектора через Connectors CSI Driver, а затем использует целевой инструмент через прокси
pipeline workload получает временное разрешение на использование чувствительного коннектора только после одобрения

Типичные примеры, которые не входят в область AccessPolicy:

чтение самого объекта Connector
просмотр веток, тегов или других ресурсов, ориентированных на UI, через Connectors API
предоставление разрешений Connectors APIs пользователям платформы

Как работает AccessPolicy

AccessPolicy располагается между определениями Connector и доступом во время выполнения:

Connector: определяет, как добраться до целевого инструмента и как аутентифицироваться
AccessPolicy: выбирает Connectors и определяет, кто может получить доступ к целевым инструментам через Connectors Proxy, предоставляемый этими Connectors
AccessRequest: фиксирует одну попытку доступа во время выполнения, требующую оценки с точки зрения одобрения
сгенерированные Role и RoleBinding: материализованные объекты RBAC, создаваемые системой из шаблонов политики

Если вам нужна общая картина того, как эти компоненты взаимодействуют, смотрите Connectors Approval & Permission Gating. Этот документ сосредоточен на проектировании политики и сопоставлении политики.

В общих чертах, процесс следующий:

Workload пытается использовать Connector через Connectors Proxy или через Connectors CSI Driver.
Система оценивает сопоставленную AccessPolicy.
Если политика использует defaultPermission и ServiceAccount workload входит в охват, доступ разрешается.
Если политика использует checkGrantedPermission, система фиксирует попытку во время выполнения в AccessRequest и предоставляет настроенное разрешение на прокси только после успешного прохождения проверок.

Схему ресурса runtime-запросов смотрите в AccessRequest API Reference.

Две модели доступа

Для одного Connector AccessPolicy обычно использует одну из двух моделей доступа через прокси:

Granting Default Proxy Access с defaultPermission: сопоставленные ServiceAccounts могут сразу получить доступ к целевому инструменту через прокси Connector
Granting Access After Approval с checkGrantedPermission: запрос во время выполнения должен пройти проверки, прежде чем будет предоставлено разрешение на прокси

На практике это означает, что доступ через один Connector обычно либо всегда разрешён в известной области, либо регулируется одобрением для чувствительного использования. Следующие два раздела сначала объясняют эти две модели, а раздел Common Configuration Patterns покажет, как ограничить их для Connectors и ServiceAccounts.

Granting Default Proxy Access

spec.defaultPermission — это часть политики, которая предоставляет доступ через прокси сразу, без каких-либо проверок одобрения.

Это обычный выбор, когда:

Connector низкорисковый внутри пространства имён или проекта
все workload в одной области должны напрямую использовать целевой инструмент через прокси Connector
нужна стабильная, не временная модель разрешений

В большинстве случаев встроенный шаблон connectors-use-connectors-proxy является правильной отправной точкой. Это шаблон роли, установленный основным компонентом Connectors, который предоставляет разрешение connectors/proxy для сопоставленного Connector.

Если Connector должен всегда быть доступен внутри пространства имён, проекта или кластера, обычно это единственный раздел разрешений, необходимый в политике.

Чтобы определить, какие Connectors и ServiceAccounts охватывает эта модель, смотрите Common Configuration Patterns.

Пример

Следующая политика даёт builder и deployer немедленный доступ через прокси ко всем OCI Connectors в devops:

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: oci-default-access
  namespace: devops
spec:
  connector:
    matchLabels:
      connectors.alauda.io/connectorclass: oci
  defaultPermission:
    roleTemplate:
      ref:
        configMap:
          name: connectors-use-connectors-proxy
    bindingTemplate:
      serviceAccounts:
        - names:
            - builder
            - deployer
          namespaceSelector:
            names:
              - devops

Granting Access After Approval

spec.checkGrantedPermission предоставляет разрешение на прокси только после успешного прохождения всех настроенных проверок.

Это обычный выбор, когда:

Connector чувствительный
доступ должен предоставляться только для одной runtime-активности
одобрение является частью процесса доставки или продвижения

Наиболее распространённая встроенная комбинация:

checks[].ref.configMap.name: connectors-approvals-in-pipeline
roleTemplate.ref.configMap.name: connectors-use-connectors-proxy-in-pod

Эта комбинация означает:

найти ресурс одобрения, связанный с объектом во время выполнения
ждать, пока результат одобрения не станет положительным
предоставить разрешение на прокси, привязанное к Pod, только для этого конкретного runtime-контекста

connectors-approvals-in-pipeline — встроенный шаблон проверки, установленный основным компонентом Connectors. В сценарии pipeline он использует runtime-контекст Pod для поиска связанной задачи Tekton ApprovalTask по tekton.dev/pipelineRun.

connectors-use-connectors-proxy-in-pod — встроенный шаблон роли, установленный основным компонентом Connectors. Он предоставляет разрешение connectors/proxy/v1/pod/{.object.metadata.namespace}/{.object.metadata.name}, которое связывает разрешение с одним конкретным Pod-контекстом, зафиксированным во время выполнения.

Вы по-прежнему используете те же шаблоны выбора Connector из Common Configuration Patterns; разница в том, что доступ предоставляется для каждого runtime-контекста после успешного прохождения проверок.

Пример

Следующая политика применяется к Connector prod-harbor. Она не даёт доступа по умолчанию. Вместо этого она ждёт встроенной проверки одобрения pipeline и затем предоставляет разрешение на прокси, привязанное к Pod.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-harbor-approval
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor
  checkGrantedPermission:
    spec:
      checks:
        - name: manual-approval
          ref:
            configMap:
              name: connectors-approvals-in-pipeline
      roleTemplate:
        ref:
          configMap:
            name: connectors-use-connectors-proxy-in-pod

Common Configuration Patterns

Выбор Connectors для защиты

AccessPolicy сопоставляется только с Connectors в том же пространстве имён, что и сама политика.

Целевые Connectors определяются в spec.connector:

оставьте пустым, чтобы сопоставить все Connectors в пространстве имён
используйте names для выбора конкретных Connectors
используйте matchLabels или matchExpressions для выбора групп Connectors

Это основной механизм для сопоставления одной политики с одним Connector, подмножеством Connectors или всеми Connectors в одной области.

Пример

Сопоставить все Connectors в текущем пространстве имён.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: allow-team-a-proxy
  namespace: team-a
spec:
  connector: {}

Сопоставить один конкретный Connector по имени.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-harbor-policy
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor

Сопоставить несколько явно указанных Connectors в одном пространстве имён.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: release-connectors
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor
      - prod-gitlab

Сопоставить все Connectors одного ConnectorClass в пространстве имён.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: all-oci-connectors
  namespace: devops
spec:
  connector:
    matchLabels:
      connectors.alauda.io/connectorclass: oci

Сопоставить подмножество Connectors по пользовательским меткам, таким как environment или usage.

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-release-connectors
  namespace: devops
spec:
  connector:
    matchExpressions:
      - key: env
        operator: In
        values:
          - prod
      - key: usage
        operator: In
        values:
          - release

Выбор ServiceAccounts, получающих доступ по умолчанию

При использовании defaultPermission в bindingTemplate.serviceAccounts определяется, какие ServiceAccounts могут использовать сопоставленный Connector через Connectors Proxy.

Каждый элемент объединяет:

names: имена ServiceAccount для привязки
namespaceSelector: из каких пространств имён эти ServiceAccounts

Используйте пустой список names, если хотите разрешить всем ServiceAccounts из выбранных пространств имён.

Пример

Разрешить всем ServiceAccounts в текущем пространстве имён. Это распространённый шаблон для Connector на уровне пространства имён.

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names: []
        namespaceSelector:
          names:
            - devops

Разрешить только выбранным ServiceAccounts в одном пространстве имён, например builder и deployer в devops.

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names:
          - builder
          - deployer
        namespaceSelector:
          names:
            - devops

Разрешить всем ServiceAccounts в одном проекте. Это полезно, когда Connector используется на уровне проекта, а пространства имён проекта помечены меткой cpaas.io/project.

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names: []
        namespaceSelector:
          matchLabels:
            cpaas.io/project: devops

Разрешить одному именованному ServiceAccount во всех пространствах имён одного проекта, например builder в проекте devops.

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names:
          - builder
        namespaceSelector:
          matchLabels:
            cpaas.io/project: devops

Разрешить всем ServiceAccounts в кластере. Это полезно для Connector, используемого на уровне кластера. В этом случае AccessPolicy должен быть создан в том же пространстве имён, что и общий Connector.
defaultPermission: roleTemplate: ref: configMap: name: connectors-use-connectors-proxy bindingTemplate: serviceAccounts: - names: [] namespaceSelector: {}

Status

AccessPolicy.status помогает операторам убедиться, что политика применена как задумано.

Важные поля статуса включают:

matchedConnectors: Connectors, которые в данный момент сопоставлены с spec.connector
conditions: статус согласования политики

Этот статус полезен для проверки того, были ли выбраны ожидаемые Connectors, прежде чем исследовать поведение доступа во время выполнения.

What's Next

Узнайте, как оценивается один запрос во время выполнения в AccessRequest
Изучите схему в AccessPolicy API Reference
Повторно ознакомьтесь с общим процессом в Connectors Approval & Permission Gating
Узнайте, как работает прокси-трафик в Connectors Proxy
Узнайте, как workloads используют Connectors через Connectors CSI Driver
Изучите отдельную модель доступа к API в Connector API

#AccessPolicy

#Содержание

#Overview

#Availability

#Understanding AccessPolicy

#Что означает «Использовать коннектор»

#Как работает AccessPolicy

#Две модели доступа

#Granting Default Proxy Access

#Пример

#Granting Access After Approval

#Пример

#Common Configuration Patterns

#Выбор Connectors для защиты

#Пример

#Выбор ServiceAccounts, получающих доступ по умолчанию

#Пример

#Status

#What's Next

AccessPolicy

Содержание

Overview

Availability

Understanding AccessPolicy

Что означает «Использовать коннектор»

Как работает AccessPolicy

Две модели доступа

Granting Default Proxy Access

Пример

Granting Access After Approval

Пример

Common Configuration Patterns

Выбор Connectors для защиты

Пример

Выбор ServiceAccounts, получающих доступ по умолчанию

Пример

Status

What's Next