☰

Kubernetes-Cronjob kann aufgrund eines Problems mit dem RBAC-Dienstkonto kein Geheimnis erstellen

tag-icon • tag-icon kubernetes rbac
Kubernetes-Cronjob kann aufgrund eines Problems mit dem RBAC-Dienstkonto kein Geheimnis erstellen

Ich versuche, die Erneuerung der ECR-Anmeldeinformationen zu automatisieren und das Token über einen CronJob geheim zu speichern. Immer wenn ich den CronJob ausführe, erhalte ich in den resultierenden Jobprotokollen den folgenden Fehler:

2023-09-14T20:11:20.326837046Z error: failed to create secret secrets is forbidden: User "system:serviceaccount:cfh:default" cannot create resource "secrets" in API group "" in the namespace "cfh"

Interessanterweise scheint dies beim Löschschritt nicht fehlzuschlagen. Ich frage mich, ob das Problem vielleicht etwas damit zu tun hat, kubectl create secret docker-registrydass es andere Rollenberechtigungen als die standardmäßigen geheimen Verben gibt, da es vom Typ ist docker-registry, aber ich bin nicht sicher.

So sieht mein CronJob-YAML aus:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: ecr-registry-helper
  creationTimestamp: '2023-09-11T00:06:03Z'
  generation: 25
  namespace: cfh
  fields:
    - ecr-registry-helper
    - 0 */10 * * *
    - 'False'
    - 0
    - 11m
    - 3d20h
    - ecr-registry-helper
    - omarxs/awskctl:v1.0
    - <none>
spec:
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 1
  jobTemplate:
    metadata:
      creationTimestamp: null
      namespace: cfh
    spec:
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
            - command:
                - /bin/bash
                - '-c'
                - >-
                  ECR_TOKEN=`aws ecr get-login-password --region ${AWS_REGION}`
            
                  NAMESPACE_NAME=cfh
            
                  kubectl delete secret --ignore-not-found regcred -n
                  $NAMESPACE_NAME
            
                  echo "deleted secret"
            
                  kubectl create secret docker-registry regcred
                  --docker-server=https://${AWS_ACCOUNT}.dkr.ecr.${AWS_REGION}.amazonaws.com
                  --docker-username=AWS --docker-password="${ECR_TOKEN}" -n $NAMESPACE_NAME
            
                  echo "Secret was successfully updated at $(date)"
              envFrom:
                - secretRef:
                    name: ecr-registry-helper-secrets
                - configMapRef:
                    name: ecr-registry-helper-cm
              image: omarxs/awskctl:v1.0
              imagePullPolicy: IfNotPresent
              name: ecr-registry-helper
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
              _init: false
              __active: true
              resources: {}
          dnsPolicy: ClusterFirst
          restartPolicy: Never
          schedulerName: default-scheduler
          serviceAccount: default
          serviceAccountName: default
          terminationGracePeriodSeconds: 30
  schedule: 0 */10 * * *
  successfulJobsHistoryLimit: 2
  suspend: false
__clone: true

Sowie mein ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  creationTimestamp: '2023-09-10T22:14:31Z'
  namespace: cfh
  fields:
    - default
    - 0
    - 3d21h
automountServiceAccountToken: false
__clone: true

Rolle

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: '2023-09-11T00:06:03Z'
  name: role-full-access-to-secrets
  namespace: cfh
rules:
  - apiGroups:
      - ''
    resourceNames:
      - regcred
    resources:
      - secrets
    verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch

Und RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: '2023-09-11T00:06:03Z'
  name: default-role-binding
  namespace: cfh
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-full-access-to-secrets
subjects:
  - kind: ServiceAccount
    name: default
    namespace: cfh

Antwort1

Vielen Dank, @veera-nagireddy, dass du mir geholfen hast, es herauszufinden (weiteren Kontext findest du in seinem Kommentar zum Originalbeitrag).

Das Problem bestand darin, dass der CronJobselbst nicht die Berechtigung hatte, Geheimnisse im cfhNamespace zu erstellen/aktualisieren, obwohl er die Rolle des übernahm ServiceAccount. Um dies zu beheben, musste ich auch ein ClusterRole& erstellen ClusterRoleBinding, das dem die Berechtigung erteilte, ServiceAccountGeheimnisse im Namespace zu mutieren cfh.

Clusterrolle:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: '2023-09-16T02:39:55Z'
  name: ecr-registry-helper-cluster-role
rules:
  - apiGroups:
      - ''
    resources:
      - secrets
    verbs:
      - create
      - delete
      - update

ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: '2023-09-16T02:42:42Z'
  name: ecr-registry-helper-cluster-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ecr-registry-helper-cluster-role
subjects:
  - kind: ServiceAccount
    name: default
    namespace: cfh

Nachdem ich diese beiden Ressourcen erstellt hatte, konnte ich das Geheimnis erfolgreich erstellen.

verwandte Informationen