Kubernetes 기초 - RBAC(1)

1. ServiceAccount                  ←  오늘 볼 내용
2. Role                   ←  오늘 볼 내용
3. RoleBinding                   ←  오늘 볼 내용
4. ClusterRole
5. ClusterRoleBinding

---

1. ServiceAccount

https://kubernetes.io/docs/concepts/security/service-accounts/

Service Accounts

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Using RBAC Authorization

 

 

ServiceAccount는 클러스터 내의 애플리케이션 또는 프로세스가 클러스터 API 서버와 상호 작용할 때 사용되는 인증 정보를 나타낸다.

ServiceAccount는 일반적으로 Pod 내에서 실행 중인 애플리케이션이나 컨테이너에 연결되어 있다.

ServiceAccount를 사용하면 클러스터 관리자가 세분화된 액세스 제어를 구현하고 각 애플리케이션에 필요한 최소 권한만 부여할 수 있다.

 

ServiceAcount의 기본 구조는 다음과 같다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
  namespace: apple

 

 

이 내용은 그저 아무런 설정이 없는 계정 하나를 생성한 것과 같다.

이제 이 ServiceAccount를 활용하려면 먼저 특정 서비스에 접근할 수 있는 권한을 생성(Role)하고 해당 권한을 계정에 연결하는 작업(RoleBinding)을 해야 한다.

그리고 권한이 부여된 계정이 있다면 이 계정을 파드 템플릿에 기재하여 해당 권한을 갖도록 할 수 있는 것이다.

 

그럼 이번에는 Role에 대해서 확인해보자.

 

 

 

---

2. Role

role은 권한을 정의하는 오브젝트다.

아래 yaml 코드는 apple이라는 네임스페이스에 Pod에 대한 조작 권한 중 get, list, create, delete에 대한 권한을 갖도록 하는 Role을 정의한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: apple
  name: test-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]

 

list는 명령이 아니라 kubectl get pods를 통해 파드 전체 목록을 가져올 수 있는 권한을 말한다.
만약 list 권한이 없다면 kubectl get pods <Pod-Name> 으로만 파드를 조회할 수 있게 된다.

 

 

apiGroups에 대한 정보는 다음과 같다.

• 기본 API 그룹 (apiGroups: [""]):
  • 주로 코어(Core) API 그룹이라고도 불린다.
  • 주요 리소스: Pods, Services, Namespaces, ConfigMaps, Events 등
• batch API 그룹 (apiGroups: ["batch"]):
  
  • 크론잡(CronJob)과 같은 작업 스케줄링을 위한 리소스를 제공한다.
  • 주요 리소스: Jobs, CronJobs 등
• apps API 그룹 (apiGroups: ["apps"]):
  • 애플리케이션 배포와 관련된 리소스를 제공한다.
  • 주요 리소스: Deployments, StatefulSets, DaemonSets, ReplicaSets 등
• networking.k8s.io API 그룹 (apiGroups: ["networking.k8s.io"]):
  • 네트워크와 관련된 리소스를 제공한다.
  • 주요 리소스: NetworkPolicies, Ingress 등
• storage.k8s.io API 그룹 (apiGroups: ["storage.k8s.io"]):
  • 스토리지와 관련된 리소스를 제공한다.
  • 주요 리소스: StorageClasses, PersistentVolumes, PersistentVolumeClaims 등
• extensions API 그룹 (apiGroups: ["extensions"]):
  • apps API 그룹에서 v1 API로 이동되거나 대체된 일부 리소스를 제공한다.

 

 

 

---

3. RoleBinding

RoleBinding은 미리 정의된 ServiceAccount와 Role을 연결하는 역할이다.

이외에도 쿠버네티스에서 생성한 User에 Role을 연결하는 역할을 한다.

 

아래는 위에서 생성한 test-sa와 test-role을 연결하는 yaml 코드다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-binding-test
  namespace: apple
subjects:
- kind: ServiceAccount
  name: test-sa
  namespace: apple
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io

 

 

Role을 적용한 ServiceAccount를 파드에 적용하는 yaml 코드다.

아래는 그냥 적용이 된다는 것만 보여주기 위해 nginx를 이미지로 사용했으나 실제로는 해당 권한이 필요한 애플리케이션에 부여를 해야 한다.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: apple
spec:
  serviceAccountName: test-sa
  containers:
    - name: nginx-container
      image: nginx

 

 

ServiceAccount의 실제 사용사례는 다양하지만 한가지 예를 들자면 Fluentd가 있다.

이전에 로깅을 위한 로그 수집 애플리케이션으로 Fluentd를 사용했는데 yaml 코드를 보면 다음과 같다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd
  namespace: kube-logging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fluentd
  namespace: kube-logging
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - namespaces
  verbs:
  - get
  - list
  - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: fluentd
roleRef:
  kind: ClusterRole
  name: fluentd
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: fluentd
  namespace: kube-logging
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-logging
  labels:
    k8s-app: fluentd-logging
    version: v1
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-logging
      version: v1
      kubernetes.io/cluster-service: "true"
  template:
    metadata:
      labels:
        k8s-app: fluentd-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccount: fluentd # if RBAC is enabled
      serviceAccountName: fluentd # if RBAC is enabled
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.1-debian-elasticsearch
        env:
        - name:  FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch-client.kube-logging.svc.cluster.local"
        - name:  FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        - name: FLUENT_ELASTICSEARCH_SCHEME
          value: "http"
        - name: FLUENT_ELASTICSEARCH_USER # even if not used they are necessary
          value: "elastic"
        - name: FLUENT_ELASTICSEARCH_PASSWORD # even if not used they are necessary
          valueFrom:
            secretKeyRef:
              name: elasticsearch-pw-elastic
              key: password
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: fluentd-config
          mountPath: /fluentd/etc # path of fluentd config file
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: fluentd-config
        configMap:
          name: fluentd-config # name of the config map we will create

 

 

Fluentd는 모든 노드에 데몬셋 형태로 배포가 되어 각 노드에 스케줄된 파드의 로그를 가져오는 역할을 하기 때문에 쿠버네티스에서 해당 권한은 필수다.

위 코드에서는 ClusterRole을 사용했으나 각 네임스페이스에 있는 파드에 대해 get, list, watch 명령을 활용할 수 있는 권한을 부여받아 실시간으로 파드의 로그를 가져올 수 있는 것이다.

 

위 사례를 Fluentd를 사용한 사례지만 이외에도 권한이 필요한 애플리케이션에 ServieAccount와 Role을 정의하여 Binding하여 사용할 수 있다.