Skip to content

Latest commit

 

History

History
60 lines (49 loc) · 1.91 KB

Lab-003.md

File metadata and controls

60 lines (49 loc) · 1.91 KB
Raw

Lab-003-RBAC

Sujet

Le but est de comprendre comment on peut restreindre les droits d'un container. En effet, on fait confiance à l'image que l'on utilise. La confiance, c'est bien, mais on n'est pas à l'abri d'une image vérolée. On va donc exprimer grâce au RBAC ce que le container aura le droit de faire ou pas.

On va chercher à interroger l'api kubernetes depuis notre container via son service.

Etape par étape

  1. création d'un namespace

  2. création d'une configmap cm-script à partir script.sh

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k https://kubernetes.default.svc/api/v1/namespaces/default/pods/ -H "Authorization: Bearer $TOKEN";

(dans kubernetes.default.svc/api/v1/namespaces/default/pods/ remplacer default par le nom du namespace créé )

  1. création d'un pod qui va utiliser cette configmap
apiVersion: v1
kind: Pod
metadata:
  name: rbac-1
spec:
  volumes:
  - name: script
    configMap:
      name: cm-script
  containers:
  - name: curl  
    command:
    - sh
    - -c
    - 'sh /scripts/script.sh'
    volumeMounts:
    - name: script
      mountPath: /scripts/ 
    image: curlimages/curl
    imagePullPolicy: Always
    resources: {}

  1. regarder les logs. Qui est vu comme utilisateur ? Peut-il interroger l'api kubernetes ?

  2. création d'un service account MYACCOUNT

  3. recréer le pod en prenant compte de ce service account dans sa définition.

  4. regarder les logs. Qui est maintenant vu comme utilisateur ? Peut-il interroger l'api kubernetes ?

  5. création d'un role qui permet de lister et voir, mais pas de détruire ni de créer des namespaces,pod.

  6. création d'un roleBinding entre ce role et ce serviceAccount

  7. recréer le pod et regarder les logs, Peut il interroger l'api kubernetes ?

  8. modifier le script et le role pour lui faire afficher les secrets.

Retour