kubernetes - API

우야·2021년 5월 24일
kubernetes
0

kubernetes에서 API란?
1. REST API는 쿠버네티스의 근본적인 구조이다.
2. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출된다.
3. 쿠버네티스 플랫폼 안의 모든 것은 API 오브젝트로 취급되고, API에 상응하는 항목이 있다.
예)

API 버전 규칙

  1. 알파(Alpha)
  • 버전 이름에 alpha가 포함된다(예: v1alpha1).
  • 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. 기본적으로 비활성화되어 있다.
  • 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
  • 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
    버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
  1. 베타(Beta)
  • 버전 이름에 beta가 포함된다(예: v2beta3).
  • 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. 기본적으로 활성화되어 있다.
  • 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
  • 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
  • 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
  1. 안정화(Stable)
  • 버전 이름이 vX이고 X 는 정수다.
  • 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.

API 그룹

  1. 쿠버네티스 API를 더 쉽게 확장
  2. API 그룹은 REST 경로와 직렬화된 오브젝트의 apiVersion 필드에 명시
    • /apis/GROUPNAME/GROUP_NAME/VERSION
    • apiVersion: GROUPNAME/GROUP_NAME/VERSION
  3. API 그룹 활성화 / 비활성화 방법
    • 특정 리소스 및 API 그룹은 기본적으로 활성화
    • API 서버에서 --runtime-config 를 설정하여 활성화 또는 비활성화
    • 비활성화 : --runtime-config=batch/v1=false
    • 활성화 : --runtime-config=batch/v2alpha1

API에 접근 방법

kubectl, 클라이언트 라이브러리, REST 요청으로 API에 접근할수 있음.

  1. 전송 보안

    • 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스하고, API 서버는 인증서를 제시함.
    • 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 $USER/.kube/config는 API 서버의 인증서에 대한 루트 인증서를 포함한다.

  2. 인증 (Authentication)

    • TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다
    • 클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성
    • 인증은 HTTP 요청이지만 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
    • 인증 모듈
      • 여러개 지정 할수 있음, 인증 성공될때까지 각 모듈이 순차적으로 시도됨
      • 클라이언트 인증서
      • 암호 및 일반 토큰
      • 부트스트랩 토큰
      • JWT 토큰(서비스 어카운트에 사용됨)
    • 인증 실패
      • HTTP 401과 함께 거부됨

  3. 인가(Authorization)

    • 요청이 인증된 후에는 인가되어야 한다
    • 절차
      1. 사용자가 요청할 수 있는 작업에 대한 정책을 선언 할수 있다.
      2. 요청에는 username, 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다.
      • 예) 1. 아래와 같이 Bob에게 projectCaribou 네임스페이스에서만 파드를 읽을수 있는 정책을 선언한다.
      • 예) 2. 아래와 같이 Bob이 projectCaribou namespace pod에 요청할수 있음.
      • create, update는할 수 없음
    • 인가 모듈
      • 가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행
      • ABAC, RBAC, WebHook mode 여러개의 인가 모듈을 지원
    • 인가 실패
      • HTTP 403과 함께 거부됨

  4. Admission Control

    • 요청을 수정하거나, 거부할 수 있는 소프트웨어 모듈
    • 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동
    • 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
    • 절차
      • 인증 및 인가 모듈과 달리, 어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
      • 어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도 필드의 복잡한 기본값을 설정할 수 있다.
      • 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후 오브젝트 저장소에 기록
      • https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
      • 클러스터 관리자만 구성할 수 있음
      • API에 구성된 변경 및 유효성 검사 (각각) 승인 제어 Webhook을 실행
        • 2단계모두 승인되어야 함.
          1. mutating 컨트롤러 실행
            • MutatingAdmissionWebhook
          2. 승인 컨트롤러 유효성 검사 실행
            • ValidatingAdmissionWebhook

API 서버 포트와 IP

  • 2개의 Port에서 HTTP를 서비스한다.
  1. localhost port:
    • 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소 (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
    • TLS가 없다.
    • 기본 포트는 8080이며, --insecure-port 플래그를 사용하여 변경한다.
    • 기본 IP는 로컬호스트(localhost)이며, --insecure-bind-address 플래그를 사용하여 변경한다.
    • 요청이 인증 및 인가 모듈을 우회한다.
    • 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
    • 호스트 접근 요구로부터 보호를 받는다.
  2. secure port
    • 가능한 항상 사용하는 것이 좋다.
    • TLS를 사용한다. --tls-cert-file 플래그로 인증서를 지정하고 --tls-private-key-file 플래그로 키를 지정한다.
    • 기본 포트는 6443이며, --secure-port 플래그를 사용하여 변경한다.
    • 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, --bind-address 플래그를 사용하여 변경한다.
    • 요청이 인증 및 인가 모듈에 의해 처리된다.
    • 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
    • 인증 및 인가 모듈을 실행한다.
profile
우야
Fullstack developer
이전 포스트

kubernetes - log

다음 포스트

Cloud Native 보안의 4C

0개의 댓글