Où puis-je obtenir une liste des ressources et sous-ressources de l'API Kubernetes?
J'essaie de configurer Kubernetes RBAC de la manière la moins permissive possible et je souhaite étendre mes rôles à des ressources et des sous-ressources spécifiques. J'ai fouillé dans les documents et je ne trouve pas une liste concise des ressources et de leurs sous-ressources.
Je suis particulièrement intéressé par la sous-ressource qui régit une partie de la spécification d'un déploiement - l'image du conteneur.
L'utilisation de kubectl api-resources -o wide Affiche tous les ressources, verbes et associés groupe 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]
...
...
Je suppose que vous pouvez l'utiliser pour créer la liste des ressources nécessaires dans votre configuration RBAC
Les ressources, sous-ressources et verbes dont vous avez besoin pour définir les rôles RBAC ne sont documentés nulle part dans une liste statique. Ils sont disponibles dans la documentation de découverte, c'est-à-dire via l'API, par ex. /api/apps/v1.
Le script bash suivant répertorie toutes les ressources, sous-ressources et verbes au format suivant:
api_version resource: [verb]
où api-version est core pour les ressources principales et doit être remplacé par "" (une chaîne entre guillemets vide) dans votre définition de rôle.
Par exemple, core pods/status: get patch update.
Le script nécessite 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
AVERTISSEMENT: Notez que là où aucun verbe n'est répertorié via l'API, la sortie affichera simplement la version de l'API et la ressource, par ex.
core pods/exec:
Dans l'instance spécifique des ressources suivantes, aucun verbe n'est affiché via l'API, ce qui est faux (bogue Kubernetes # 65421 , corrigé par # 65518 ):
nodes/proxy
pods/attach
pods/exec
pods/portforward
pods/proxy
services/proxy
Les verbes pris en charge pour ces ressources sont les suivants:
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
AVERTISSEMENT 2: Parfois, Kubernetes vérifie les autorisations supplémentaires à l'aide de verbes spécialisés qui ne sont pas répertoriés ici. Par exemple, le verbe bind est nécessaire pour les ressources roles et clusterroles dans le rbac.authorization.k8s.io Groupe API. Les détails de ces verbes spécialisés se trouvent dans le docs here .
Vous pouvez trouver la liste des ressources de Kubernetes v1.9 ici: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#-strong-api-overview-strong- . Pour les autres versions de K8, consultez la section 'Référence API' sur https://kubernetes.io/docs/reference/
Consultez le catalogue sur le côté gauche, par exemple, "Workloads" est la vue d'ensemble de haut niveau des types de ressources de base tels que Container, Deployment, CronJob etc. Ressources de l'API Kubernetes.
Vous pouvez accéder à ces ressources de base via kubectl, il existe donc également une liste de 'types de ressources' disponibles dans https://kubernetes.io/docs/reference/kubectl/cheatsheet/
Mais je suis confus dans votre déclaration "la sous-ressource qui régit une partie de la spécification d'un déploiement - l'image du conteneur", si vous essayez de gérer les autorisations d'une image de conteneur, vous devez le faire sur votre registre d'images, mais pas du côté de Kubernetes. Par exemple, votre registre devrait avoir un contrôleur d'accès pour effectuer l'authentification lorsque l'utilisateur extrait des images.
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'
J'hésite même à mettre cela comme une "réponse", mais c'est certainement trop long pour un commentaire
Pour la liste des ressources, connaissez-vous $HOME/.kube/cache/discovery dans lequel les fichiers Swagger JSON sont conservés sur le disque par un répertoire correspondant à leur apiVersion? Ceci est le lien le plus rapide que j'ai pu trouver (regardez dans la rubrique "Découverte et utilisation des CRD") mais ls -la ~/.kube/cached/discovery montrera ce que je veux dire. Ces fichiers Swagger JSON énumèrent tous les principaux acteurs d'un apiVersion d'une manière que je trouve beaucoup plus accessible que le site Web de référence de l'API.
Je n'ai pas ces fichiers devant moi pour savoir s'ils contiennent des définitions de sous-ressources, alors j'espère que quelqu'un d'autre pourra y peser.
L'astérisque mineur de la partie "peser" est que, sur la base de la navigation que j'ai faite des documents RBAC et de la référence API 1.9, je n'ai pas eu l'impression qu'une sous-ressource est un "accès au niveau du champ" à sa ressource parent. Par exemple, v1beta1/Evictions est une sous-ressource Pod de /evictions qui, à ma connaissance, n'est pas un champ dans PodSpec
Donc, si vous êtes intéressé à faire RBAC pour limiter l'image d'un déploiement, vous pouvez être beaucoup plus heureux avec Mode Webhook où l'on peut ont une logique commerciale presque illimitée appliquée à la tentative de demande.