Учетная запись службы не уважает свою роль кластера - PullRequest
0 голосов
/ 28 ноября 2018

Я создал контекст с пользователем, который имеет только доступ READ , но когда я вошел в систему как этот пользователь, я все еще могу делать все, что захочу, например развертывание и уничтожение модулей и т. Д. Почему?Это что?


Я следовал этому учебнику .

1) Сначала я создал учетную запись службы:
kubectl create sa myserviceaccount

2) Теперь мне нужна роль с минимальным разрешением ( просто ЧИТАТЬ ), поэтому я возьму одну из системы кубов, которая называется " view "

 $ kubectl describe clusterrole view
  Resources                                Non-Resource URLs  Resource Names  Verbs
  ---------                                -----------------  --------------  -----
  bindings                                 []                 []              [get list watch]
  configmaps                               []                 []              [get list watch]
  [...]

3) Теперь я должен создать clusterRoleBinding, чтобы привязать учетную запись службы к роли "view"

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: crbmyserviceaccount
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: ServiceAccount
  name: myserviceaccount
  namespace: default

4) Теперь мы должны найти соответствующее секретное имя

kubectl get secrets -> myserviceaccount-token-bmwwd

5) Сохраните отображаемый токен где-нибудь (для использования позже)

kubectl describe secret myserviceaccount-token-xxxxx

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

6) Настройка кластера в kubeconfig: kubectl config set-cluster myawesomecluster --server=IP-OF-MY-CLUSTER

7) Создание учетных данных:

kubectl config set-credentials myawesomecluster-myserviceaccount --token=TOKEN-FROM-STEP-5

8) Создание контекстаt

kubectl config set-context myawesomecluster --cluster=myawesomecluster --user=myawesomecluster-myserviceaccount --namespace=default
kubectl config use-context myawesomecluster

Тааддаааа!

Теперь, когда контекст установлен, я смогу ПРОЧИТАТЬ все ресурсы, но не создавать их.К сожалению, я все еще могу выполнять развертывания с использованием kubectl или даже удалять модули и т. Д.

Это должно вернуть мне отказ в доступе: kubectl create -f someFileWithDeployment

Что я делаю не так?
Thx!


Редактировать - Добавление вывода пространств имен и представления конфигурации для целей отладки:

$kubectl get sa
NAME               SECRETS   AGE
api-explorer       1         39h
default            1         5d22h
myserviceaccount   1         17h


$kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/xxxx/rbac/accountTest/api-            explorer/context/team-a-decoded.crt
    server: http://127.0.0.1:8080
  name: cfc
- cluster:
    server: http://127.0.0.1:8080
  name: myawesomecluster
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: http://localhost:8080
  name: test-cluster
contexts:
- context:
    cluster: cfc
    user: user
  name: cfc
- context:
    cluster: ""
    user: ""
  name: default
- context:
    cluster: myawesomecluster
    namespace: default
    user: myawesomecluster-myserviceaccount
  name: myawesomecluster
current-context: myawesomecluster
kind: Config
preferences: {}
users:
- name: api-explorer
  user:
    token: ZXlKaGJHY2l[...]
- name: myawesomecluster-myserviceaccount
  user:
    token: eyJhbGci [...]
- name: user
  user:
    token: ZXlKaGJH

Редактировать 2: Отображениевывод get pod kube-apiserver-nodemaster1

$kubectl get pod kube-apiserver-nodemaster1 -n kube-system -o yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/config.hash: 034c3[...]
    kubernetes.io/config.mirror: 034b3[...]
    kubernetes.io/config.seen: 2018-11-23T09:48:59.766423346Z
    kubernetes.io/config.source: file
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: 2018-11-23T09:50:29Z
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver-nodemaster1
  namespace: kube-system
  resourceVersion: "804213"
  selfLink: /api/v1/namespaces/kube-system/pods/kube-apiserver-nodemaster1
  uid: 36340f[...]
spec:
  containers:
  - command:
    - kube-apiserver
    - --allow-privileged=true
    - --apiserver-count=3
    - --authorization-mode=Node,RBAC
    - --bind-address=0.0.0.0
    - --endpoint-reconciler-type=lease
    - --insecure-bind-address=127.0.0.1
    - --insecure-port=8080
    - --kubelet-preferred-address-types=InternalDNS,InternalIP,Hostname,ExternalDNS,ExternalIP
    - --runtime-config=admissionregistration.k8s.io/v1alpha1
    - --service-node-port-range=30000-32767
    - --storage-backend=etcd3
    - --advertise-address=10.10.10.101
    - --client-ca-file=/etc/kubernetes/ssl/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/ssl/etcd/ca.pem
    - --etcd-certfile=/etc/kubernetes/ssl/etcd/node-nodemaster1.pem
    - --etcd-keyfile=/etc/kubernetes/ssl/etcd/node-nodemaster1-key.pem
    - --etcd-servers=https://10.10.10.101:2379,https://10.10.10.102:2379,https://10.10.10.103:2379
    - --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/ssl/apiserver-kubelet-client.key
    - --proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/ssl/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-key-file=/etc/kubernetes/ssl/sa.pub
    - --service-cluster-ip-range=10.233.0.0/18
    - --tls-cert-file=/etc/kubernetes/ssl/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/ssl/apiserver.key
    image: gcr.io/google-containers/kube-apiserver:v1.12.2
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 10.10.10.101
        path: /healthz
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 15
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 15
    name: kube-apiserver
    resources:
      requests:
        cpu: 250m
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /etc/kubernetes/ssl
      name: k8s-certs
      readOnly: true
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
  dnsPolicy: ClusterFirst
  hostNetwork: true
  nodeName: nodemaster1
  priority: 2000000000
  priorityClassName: system-cluster-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    operator: Exists
  volumes:
  - hostPath:
      path: /etc/kubernetes/ssl
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-11-23T09:55:05Z
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: 2018-11-23T09:55:05Z
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: 2018-11-23T09:55:05Z
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: 2018-11-23T09:55:05Z
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://8287[...]
    image: gcr.io/google-containers/kube-apiserver:v1.12.2
    imageID: docker-pullable://gcr.io/google-containers/kube-apiserver@sha256:0949[...]
    lastState:
      terminated:
        containerID: docker://e97[...]
        exitCode: 0
        finishedAt: 2018-11-27T14:18:24Z
        reason: Completed
        startedAt: 2018-11-23T09:49:00Z
    name: kube-apiserver
    ready: true
    restartCount: 1
    state:
      running:
        startedAt: 2018-11-27T14:18:24Z
  hostIP: 10.10.10.101
  phase: Running
  podIP: 10.10.10.101
  qosClass: Burstable
  startTime: 2018-11-23T09:55:05Z

Ответы [ 2 ]

0 голосов
/ 04 декабря 2018

Как объяснил @mk_sta, мне пришлось использовать конечную точку HTTPS, а не http-точку по умолчанию.Конечная точка Http рассматривается как устаревшая и, вероятно, будет удалена, как объяснено здесь

Чтобы пройти через конечную точку https, замените шаг 6:

kubectl config set-cluster myawesomecluster --server=https://127.0.0.1:6443

Теперь вы будетевозможно, произошла ошибка SLL.
Что я сделал, так это изменил свой файл kubeconfig (в ~ / .kube / config).
Я добавил ключ "сертификат-центр" со значением путь, по которому kubernetes хранит свой главный сертификат .
Окончательная конфигурация кластера теперь выглядит следующим образом:

- cluster:
    certificate-authority: /etc/kubernetes/ssl/ca.crt
    server: https://127.0.0.1:6443
  name: secureRemote
0 голосов
/ 03 декабря 2018

Я предполагаю, что при использовании флагов --insecure-bind-address=127.0.0.1 и --insecure-port=8080 в конфигурации kube-apiserver все запросы к серверу API Kubernetes обходят авторизацию модуля RBAC, как описано в официальной документации Kubernetes :

Порт локального хоста:

  • предназначен для тестирования и начальной загрузки, а также для других компонентов главного узла (планировщик, контроллер-менеджер) для связи с API
  • нет TLS
  • по умолчанию используется порт 8080, изменяется с флагом --insecure-port.
  • IP-адрес по умолчанию - localhost, изменяется с флагом --insecure-bind-address.
  • запрос обходит модули аутентификации и авторизации.
  • запрос обрабатывается модулями (ами) контроля доступа.
  • защищен необходимостью иметь доступ к хосту
...