Как отказаться от реестров докеров в Куберне?

Question

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

Например, мое имя реестра - registry.my.com.Я хочу, чтобы kubernetes извлекал / запускал изображения только из registry.my.com, поэтому:

image: prometheus:2.6.1

или любое другое должно быть отклонено, в то время как:

image: registry.my.com/prometheus:2.6.1

не должно.

Есть ли способ сделать это?

Answer 1

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

Если вы работаете на платформе redhat и запускаете только узлы docker или kubernetes на RHEL, с докером RHEL в качестве среды выполнения контейнера, вы можете записать туда белые реестры.

Docker для белых списковРеестры

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

Чтобы настроить белый список:

Отредактируйте файл /etc/sysconfig/docker взаблокировать все реестры:

BLOCK_REGISTRY='--block-registry=all'

Может потребоваться раскомментировать строку BLOCK_REGISTRY.

В том же файле добавить реестры, к которым вы хотите разрешить доступ:

ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'
Allowing Access to Registries
ADD_REGISTRY='--add-registry=registry.access.redhat.com'

Существует также проект github:

https://github.com/flavio/kube-image-bouncer

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

Answer 2

Контроллеры доступа - это то, что вы ищете.

Контроллеры доступа перехватывают операции для проверки того, что должно произойти, прежде чем операция будет совершена api-сервером.

Примером является ImagePolicyWebhook , контроллер доступа, который перехватывает операции Image для проверки, следует ли ему разрешить или отклонить.

Он вызовет конечную точку REST с такой полезной нагрузкой, как:

{  
  "apiVersion":"imagepolicy.k8s.io/v1alpha1",
  "kind":"ImageReview",
  "spec":{  
    "containers":[  
      {  
        "image":"myrepo/myimage:v1"
      },
      {  
        "image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations":[  
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    ],
    "namespace":"mynamespace"
  }
}

и ответ API: Разрешено :

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}

или Отклонено :

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

Конечная точкаэто может быть лямбда-функция или контейнер, работающий в кластере.

В этом репозитории github github.com / flavio / kube-image-bouncer реализован пример с использованием ImagePolicyWebhook для отбраковки контейнеров с помощью тега «Последние».

Существует также возможность использовать флаг registry-whitelist при запуске, чтобы передать список разрешенных реестров через запятую, это будет использоваться ValidatingAdmissionWebhook для проверки, если реестр внесен в белый список.

.

Другой альтернативой является проект Открытый агент политики [OPA].

OPA - это гибкий механизм, используемый для создания политик, основанных на правилах, для сопоставления ресурсов и принятия решений в соответствии с результатами этих выражений.Это мутирующий и проверяющий веб-крючок, который вызывается для сопоставления запросов сервера Kubernetes API от контроллера доступа, упомянутого выше.Таким образом, операция будет работать так же, как описано выше, с той лишь разницей, что правила пишутся как конфигурация, а не как код.Тот же пример вышеописанного переписывателя для использования OPA будет похож на это:

package admission

import data.k8s.matches

deny[{
    "id": "container-image-whitelist",  # identifies type of violation
    "resource": {
        "kind": "pods",                 # identifies kind of resource
        "namespace": namespace,         # identifies namespace of resource
        "name": name                    # identifies name of resource
    },
    "resolution": {"message": msg},     # provides human-readable message to display
}] {
    matches[["pods", namespace, name, matched_pod]]
    container = matched_pod.spec.containers[_]
    not re_match("^registry.acmecorp.com/.+$", container.image) # The actual validation
    msg := sprintf("invalid container registry image %q", [container.image])
}

Вышеприведенное означает: запретить любой модуль, если изображение контейнера не соответствует следующему реестру registry.acmecorp.com