Где я могу получить список ресурсов и субресурсов API Kubernetes?

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

Меня особенно интересует подресурс, который управляет частью спецификации развертывания - образом контейнера.

12 ответов

С помощью kubectl api-resources -o wide показывает все ресурсы, глаголы и связанные API-группы.

$ kubectl api-resources -o wide
NAME                              SHORTNAMES     APIGROUP                       NAMESPACED   KIND                             VERBS
bindings                                                                        true         Binding                          [create]
componentstatuses                 cs                                            false        ComponentStatus                  [get list]
configmaps                        cm                                            true         ConfigMap                        [create delete deletecollection get list patch update watch]
endpoints                         ep                                            true         Endpoints                        [create delete deletecollection get list patch update watch]
events                            ev                                            true         Event                            [create delete deletecollection get list patch update watch]
limitranges                       limits                                        true         LimitRange                       [create delete deletecollection get list patch update watch]
namespaces                        ns                                            false        Namespace                        [create delete get list patch update watch]
nodes                             no                                            false        Node                             [create delete deletecollection get list patch update watch]
persistentvolumeclaims            pvc                                           true         PersistentVolumeClaim            [create delete deletecollection get list patch update watch]
persistentvolumes                 pv                                            false        PersistentVolume                 [create delete deletecollection get list patch update watch]
pods                              po                                            true         Pod                              [create delete deletecollection get list patch update watch]
statefulsets                      sts            apps                           true         StatefulSet                      [create delete deletecollection get list patch update watch]
meshpolicies                                     authentication.istio.io        false        MeshPolicy                       [delete deletecollection get list patch create update watch]
policies                                         authentication.istio.io        true         Policy                           [delete deletecollection get list patch create update watch]
...
...

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

Ресурсы, подресурсы и глаголы, необходимые для определения ролей RBAC, не документированы нигде в статическом списке. Они доступны в документации по обнаружению, т.е. через API, например /api/apps/v1,

Следующий скрипт bash перечислит все ресурсы, подресурсы и глаголы в следующем формате:

api_version resource: [verb]

где api-version является core для основных ресурсов и должны быть заменены "" (пустая строка в кавычках) в вашем определении роли.

Например, core pods/status: get patch update,

Сценарий требует JQ.

#!/bin/bash
SERVER="localhost:8080"

APIS=$(curl -s $SERVER/apis | jq -r '[.groups | .[].name] | join(" ")')

# do core resources first, which are at a separate api location
api="core"
curl -s $SERVER/api/v1 | jq -r --arg api "$api" '.resources | .[] | "\($api) \(.name): \(.verbs | join(" "))"'

# now do non-core resources
for api in $APIS; do
    version=$(curl -s $SERVER/apis/$api | jq -r '.preferredVersion.version')
    curl -s $SERVER/apis/$api/$version | jq -r --arg api "$api" '.resources | .[]? | "\($api) \(.name): \(.verbs | join(" "))"'
done

ВНИМАНИЕ: Обратите внимание, что если в API не указаны глаголы, в выходных данных просто отобразится версия API и ресурс, например

core pods/exec:

В конкретном случае следующих ресурсов через API не отображаются глаголы, что неверно (ошибка Kubernetes # 65421, исправленная # 65518):

nodes/proxy
pods/attach
pods/exec
pods/portforward
pods/proxy
services/proxy

Поддерживаются следующие глаголы для этих ресурсов:

nodes/proxy: create delete get patch update
pods/attach: create get
pods/exec: create get
pods/portforward: create get
pods/proxy: create delete get patch update
services/proxy: create delete get patch update

ВНИМАНИЕ 2: Иногда Kubernetes проверяет наличие дополнительных разрешений, используя специальные глаголы, которые здесь не перечислены. Например, bind глагол нужен для roles а также clusterroles ресурсы в rbac.authorization.k8s.io API группа. Детали этих специализированных глаголов можно найти в документации здесь.

Я стесняюсь даже назвать это "Ответом", но это, безусловно, слишком долго для комментария

Для списка ресурсов, вы знаете о $HOME/.kube/cache/discovery где файлы JSON Swagger сохраняются на диск в каталоге, который соответствует их вложению apiVersion? Это самая быстрая ссылка, которую я смог найти (см. Заголовок "Обнаружение и использование CRD"), но ls -la ~/.kube/cached/discovery покажет, что я имею в виду. Эти файлы Swson JSON перечисляют всех основных игроков в apiVersion таким образом, я нахожу намного более доступным, чем справочный сайт API.

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

Небольшая звездочка в части "взвешивания" заключается в том, что, основываясь на просмотре документов RBAC и справке API 1.9, я не создавал впечатление, что подресурс - это "доступ на уровне поля" к его родительскому ресурсу. Например, v1beta1 / Evictions является субресурсом Pod /evictions которая, насколько мне известно, не является областью в PodSpec

Поэтому, если вы заинтересованы в создании RBAC для ограничения образа Deployment, вы можете быть намного счастливее с режимом Webhook, где можно применить практически неограниченную бизнес-логику, примененную к предпринятому запросу.

for kind in `kubectl api-resources | tail +2 | awk '{ print $1 }' | sort`; do kubectl explain $kind ; done | grep -e "KIND:" -e  "VERSION:" | awk '{print $2}' | paste -sd' \n'

Вы можете найти список ресурсов Kubernetes v1.9 здесь: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/. Для других версий K8s обратитесь к разделу "Справочник по API" на https://kubernetes.io/docs/reference/

Проверьте каталог с левой стороны, например, "Рабочие нагрузки" - это общий обзор основных типов ресурсов, таких как "Контейнер", "Развертывание", "CronJob" и т. Д. И эти подресурсы, такие как "" Контейнер, Развертывание, CronJob "", являются типичными основными Ресурсы Kubernetes API.

Вы можете получить доступ к этим основным ресурсам через kubectl, следовательно, там также есть список "Типов ресурсов", доступный в https://kubernetes.io/docs/reference/kubectl/cheatsheet/

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

Версия Markdown с использованием kubectl вместо curl

Ниже следует другой фрагмент кода, полученный из сценария, опубликованного в ответе Джоном .
При выполнении в Bash он производит более подробный вывод в виде таблицы Markdown , сохраненной в виде файла. Kubernetes_API_resources.md.
Оно использует kubectl get --raw ... вместо curl для запроса API, и полученный файл Markdown документирует собственное создание в блоке кода.

      echo "# Kubernetes API resources

Updated on `date -I`

\`\`\`bash
${BASH_COMMAND}
\`\`\`

| API name/version | Resource | Verbs | Kind | Namespaced |
| ---------------- | -------- | ----- | ---- | ---------- |
`
for apipath in $(kubectl api-versions | sort | sed '/\//{H;1h;$!d;x}'); do
  version=${apipath#*/}
  api=${apipath%$version}
  api=${api%/}
  prefix="/api${api:+s}/"
  api=${api:-(core)}
  >&2 echo "${prefix}${apipath}: ${api}/${version}"
  kubectl get --raw "${prefix}${apipath}" | jq -r --arg api "${api}/${version}" '.resources | sort_by(.name) | .[]? | "| \($api) | \(.name) | \(.verbs | join(" ")) | \(.kind) | \(if .namespaced then "true" else "false" end) |"'
done
`" > Kubernetes_API_resources.md

Существует плагин kubectl — rbac-tool , в котором есть новая подкоманда, которая выводит доступные разрешения для доступных ресурсов (и подресурсов).

под капотом он использует клиент динамического API Kubernetes для получения ресурсов API сервера для всех групп.

Например:

      $kubectl rbac-tool show --for-groups=,apps
      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations: null
  creationTimestamp: null
  labels: null
  name: custom-cluster-role
rules:
- apiGroups:
  - ""
  resources:
  - bindings
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - componentstatuses
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - limitranges
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces/finalize
  verbs:
  - update
- apiGroups:
  - ""
  resources:
  - namespaces/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - nodes/proxy
  verbs:
  - create
  - delete
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - persistentvolumeclaims
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - persistentvolumeclaims/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - persistentvolumes/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - pods/attach
  verbs:
  - create
  - get
- apiGroups:
  - ""
  resources:
  - pods/binding
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
  - get
- apiGroups:
  - ""
  resources:
  - pods/log
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - pods/portforward
  verbs:
  - create
  - get
- apiGroups:
  - ""
  resources:
  - pods/proxy
  verbs:
  - create
  - delete
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - pods/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - podtemplates
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - replicationcontrollers
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - replicationcontrollers/scale
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - replicationcontrollers/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - resourcequotas
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - resourcequotas/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - services/proxy
  verbs:
  - create
  - delete
  - get
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - controllerrevisions
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - apps
  resources:
  - daemonsets
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - apps
  resources:
  - daemonsets/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - apps
  resources:
  - deployments/scale
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - deployments/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - replicasets
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - apps
  resources:
  - replicasets/scale
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - replicasets/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - statefulsets
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - apps
  resources:
  - statefulsets/scale
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - apps
  resources:
  - statefulsets/status
  verbs:
  - get
  - patch
  - update

Именно для этой цели я написал крошечную утилиту Go. Создает полную роль RBAC со всеми возможными ресурсами и подресурсами в кластере. Затем вы можете обрезать его, чтобы он соответствовал сценарию использования вашей роли.

https://github.com/coopernetes/kube-role-gen

бегатьkubectl proxy, сервер начнет работать по адресу http://127.0.0.1:8001/ . так что просто откройте его в браузере, вы увидите все API-ресурсы

Вы можете использовать команду объяснения, чтобы получить подробную информацию о режиме API-ресурса и подресурсов.

Здесь я беру пример API-ресурса POD:

      kubectl explain pod

KIND:     Pod
VERSION:  v1
DESCRIPTION:
    Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.

Если вы хотите узнать больше о разделе спецификаций (подресурсе) POD, используйте

      kubectl explain pod.spec

Для терпимости

      kubectl explain pod.spec.tolerations

и если вы хотите получить контрольные значения и использовать его тип ввода

      kubectl explain pod.spec.tolerations.value

введите описание изображения здесь

Надеюсь это ответит на твой вопрос

Другой вариант, особенно для тех, у кого нет немедленного доступа к живому k8s, это OpenAPIспец.
Из справки по api вы можете получить доступ к последним документам, в которых есть ссылка в правом верхнем углу на управляемую git спецификацию OpenAPI, которую вы можете загрузить в живом веб-редакторе Swagger.
Конечные точки вроде /api/v1/namespaces/{namespace}/pods/{name}/log будут там перечислены.

Разместил все эти ссылки в попытке защитить этот ответ в будущем. Я не мог найти /latest введите URL-адрес, указывающий на последнюю версию.

Если вы используете плагин kubectl krew, я предлагаю использовать get-all. Он может получить почти 90% ресурсов. включены configmap, secret, endpoints, istio и т. д.

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

пример

kubectl get-all --since 1d

Другие вопросы по тегам