[쿠버네티스] 7. 보안 (3) API 그룹들, kubectl proxy

1. API 그룹

1) API 그룹이란?

(1) 정의: Kubernetes의  리소스를 논리적으로 그룹화하여 관리하는 그룹. 새로운 기능을 추가하거나 기존 기능을 유지 관리하기 쉽게 만들어줌. 

- 각 그룹에서는 특정 리소스(pod 등)과 동작('get','create','delete')을 정의합니다. 

(2) 필요성:

- 리소스의 모듈화: API를 모듈화하여 필요한 리소스의 경우, 해당 모듈에만 추가함으로써, 확장가능성을 높였다. 또한 각 리소스 API 그룹마다 충돌하지 않도록 모듈처럼 설계하였다.

2) 보안성:

- 일부 API 그룹들의 엔드포인트는 공개적으로 내용을 조회할 수 있지만, 일부는 그렇지 않다. 

- 조회하기 위해서 추가적인 승인절차가 요구된다. 

(1) 공개 API 그룹들:

- Kubernetes API 서버의 상태를 확인하거나 디버깅 목적으로 사용되며, 보안 요구사항이 낮은 정보를 제공하여, 기본적으로 추가적인 인증이 요구되지 않는다. 

- `/metrics`: API 서버의 성능 및 상태 관련 메트릭 데이터(모니터링 데이터)를 반환

- `/healthz`: API 서버의 상태를 확인하는 데이터를 반환   

- `/version`: API 서버의 버전 정보를 반한 

- `/logs`: API 서버의 로그 데이터를 반환

- 인증없이 접근할 수 있으므로, 민감한 정보가 노출되지 않기 위해서는 네트워크 레벨(방화벽을 통한 IP 차단)을 고려해야한다. 

##curl 을 통한 version 정보 조회 

curl https://kube-master:6443/version

## 버전 정보 반환 (인증 불필요
{
  "major": "1",
  "minor": "23",
  "gitVersion": "v1.23.6",
  "gitCommit": "abcdef123456",
  "gitTreeState": "clean",
  "buildDate": "2022-03-15T12:34:56Z",
  "goVersion": "go1.17.8",
  "compiler": "gc",
  "platform": "linux/amd64"
}

(2) 비공개 API 그룹:

- 클러스터 리소스에 접근하기 위한 API 그룹과 엔드포인트로 추가적인 인증과 권한 부여가 요청된다. 

- `api` , `apis` 그룹으로 pod, nodes 등 다양한 쿠버네티스 자원을 관리한다. 

 

##추가 인증정보 없이 요청할 경우
curl https://kube-master:6443/api/v1/pods

##Failed Return
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}

##인증정보 포함해서 요청할 경우
 curl http://kube-master:6443 –k--key admin.key--cert admin.crt --cacert ca.crt
 
##Success Return
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/pods",
    "resourceVersion": "12345"
  },
  "items": [
    {
      "metadata": {
        "name": "nginx-pod",
        "namespace": "default",
        ...
      },
      ...
    }
  ]
}

2) Core API Group(`/api`)

(1) 정의

- Kubernetest의 핵심리소스들이 포함된 기본 그룹으로 클러스터의 기본적인 동작을 지원한다. 

- 별도의 그룹 이름이 없으며, API 엔드포인트는 `/api/v1/`으로 시작한다. (즉 기본 리소스이므로 바로 그룹이름을 지칭할 필요없이 리소스를 사용하도록 하는 것이다.)<=> 'named' API

(2)포함된 리소스

- Pods, Services, Namespaces, ConfigMaps, PersistentVolumes, PersistentVolumeClaims, Nodes, Secrets

##Core Apigroup 예시

apiVersion: v1  # Core Group은 그룹 이름 없이 v1만 사용
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest

 

3) Named API Group(`/apis`)

(1) 특징

- Core API Group 외에 이름이 지정된 모든 그룹을 포함

- 새로운 기능이나 확장성을 제공하기 위해 설계

- 각 그룹은 특정 목적에 따라 리소스를 논리적으로 분류 

- 엔드포인트는 `/apis/<그룹이름>/<버전>`형식으로 사용

(2) 주요 리소스

- apps: deplyments,statefulsets, daemonsets 등 application 관련 리소스

- batch: Jobs, CronJobs 등 배치 작업 관련 리소스

- networking.k8s.io: Netwrokpolices, ingress 등 네트워크 관련 리소스 

- rbac.authorization.k8s.io: role, rolebinding, clusterrole, clusterrole binding 등 rbac 관련 리소스 

- storage.k8s.io:storageclasses, volumeattachments 등 스토리지 관련 리소스 

## 접근 예시  그룹명과 버전을 명시함을 확인
curl https://kube-master:6443/apis/apps/v1/deployments 

## yaml 파일 예시
apiVersion: apps/v1  # Named Group은 그룹 이름과 버전을 명시해야 함
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx:latest

2. Kubectl proxy

1) kubectl proxy란?

(1) 정의

- 로컬 머신에서 kubernetes API 서버에 대한 프록시 서버를 생성하는 명령어

- 프록시를 통해 kubernetes api와 상호작용을 대신 함으로써, 인증 및 보안 일정을 간소화하며, 로컬환경에서도 클러스터 API에 대한 안전한 접근을 가능하게 한다. (로컬머신에서만 접근가능하도록 하여 외부 네트워크에 노출이 되지 않는다)

(2) 역할

- 로컬 머신에서 kubernetes api 서버로의 프록시를 생성 

- API 요청을 로컬 주소(ex) localhost:8001)로 라우팅하여 클러스터와 통신

- 클라이언트가 직접 인증정보를 관리하지 않아도 되도록 인증을 처리

(3) 작동방식

- `kubectl proxy`를 실행하면, 로컬 머신에서 HTTP 서버가 생성된다. 

##프록시 생성 `localhost:8001`
kubectl proxy

##실행 후 확인 
Starting to serve on 127.0.0.1:8001


##특정포트 실행 `8080 포트에 실행`
kubectl proxy --port=8080

 

- 생성된 프록시를 통해 API서버로 요청과 응답을 주고 받는다. 

- 인증을 위해서는 인증헤더를 프록시에서 자동으로 추가한다. (인증토큰이나 인증서를 클라이언트에서 관리할 필요가 없다) 

- Core Group 이나 Namedgroup 엔드포인트 접근할때도 프록시에 사용한다

## core group에 localhost:8001 프록시로 접근
curl http://localhost:8001/api/v1/pods

## named group에 localhost:8001 프록시로 접근 
curl http://localhost:8001/apis/apps/v1/deployments

 

(4) 한계점

- 로드밸런싱 미지원: failover가 지원되지 않는다.

- 로컬 머신 의존성: 로컬환경에 문제가 생기면, 클러스터 접근이 중단된다. 

 

3) kube-proxy != kubectl proxy

(1) kube-proxy:쿠버네티스 프록시 클러스터의 네트워크 트래픽을 관리하는 네트워크 프록시 

- 클러스터 내에서 service와 pods간의 통신을 가능하게 하는 역할을 수행한다. 

- kubernetes 클러스터의 모든 노드에서 실행되며, 네트워크 라우팅을 수행한다. 

- Service-to-pod 트래픽 관리: Service가 여러 Pod에 트래픽을 로드밸런싱하는 것을 진행

- iptable: 라우팅 테이블을 통해 네트워크 라우팅을 수행 및 규칙 설정 가능 

- Daemonset: 모든 노드에서 실행되는 daemonset

(2)차이

-kubectl proxy: 로컬머신에서 API 서버로의 HTTP 프록시 

-kube-proxy: service-to-pod 간의 네트워크 트래픽을 전달하고 관리