기금넷 공식사이트 - 복권 조회 - K8s API 호출
K8s API 호출
위 단계 1 과 같이 TLS 가 설정되면 HTTP 요청이 인증 단계로 들어갑니다. 클러스터 생성 스크립트 또는 클러스터 관리자는 하나 이상의 인증 구성 요소를 실행하도록 API 서버를 구성합니다.
인증 단계에서는 전체 HTTP 요청을 입력하지만 구성 요소는 일반적으로 헤드 및 클라이언트 인증서만 확인합니다.
인증 모듈에는 클라이언트 인증서, 암호, 일반 토큰, 부팅 토큰 및 JSON 웹 토큰 (서비스 계정용 JWT) 이 포함됩니다.
둘 이상의 인증 모듈을 지정할 수 있습니다. 이 경우 서버는 모듈 중 하나가 성공할 때까지 각 인증 모듈을 차례로 시도합니다.
요청된 인증이 실패할 경우 서버는 HTTP 상태 코드 40 1 을 사용하여 요청을 거부합니다. 대신, 사용자는 특정 사용자 이름으로 인증되며, 그 사용자 이름은 다음 단계에서 그의 결정에 사용될 수 있습니다. 일부 인증 코드는 사용자의 그룹 멤버쉽을 제공하는 반면 다른 인증 코드는 제공하지 않습니다.
위의 2 단계에서 알 수 있듯이 인증 요청이 특정 사용자로부터 온 후에는 요청을 인증해야 합니다.
요청에는 요청자의 사용자 이름, 요청 동작 및 작업의 영향을 받는 객체가 포함되어야 합니다. 기존 정책에서 사용자가 요청된 작업을 완료할 권한이 있다고 선언하면 요청이 인증됩니다.
Kubernetes 는 ABAC 모드, RBAC 모드 및 Webhook 모드와 같은 다양한 인증 모듈을 지원합니다. 관리자는 클러스터를 생성할 때 API 서버에서 사용해야 하는 인증 모듈을 구성합니다. 둘 이상의 인증 모듈이 구성된 경우 Kubernetes 는 각 모듈을 검사합니다. 모듈에서 요청을 확인한 경우 요청을 계속할 수 있습니다. 모든 모듈에서 요청을 거부하면 요청이 거부됩니다 (HTTP 상태 코드 403).
라이센스 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈입니다. 액세스 제어 모듈은 인증 모듈에서 사용할 수 있는 속성 외에도 생성 또는 수정된 개체의 내용에 액세스할 수 있습니다.
액세스 컨트롤러는 에이전트를 통해 개체를 생성, 수정, 삭제 또는 연결하기 위한 요청을 조작합니다. 액세스 컨트롤러는 읽기 전용 개체의 요청을 처리하지 않습니다. 여러 액세스 컨트롤러가 구성된 경우 서버는 차례로 해당 컨트롤러를 호출합니다.
이 작업은 위의 3 단계와 같습니다.
인증 및 검증 모듈과 달리 액세스 컨트롤러 모듈이 요청을 거부하면 즉시 거부됩니다.
액세스 컨트롤러는 개체를 거부하는 것 외에도 필드에 대해 복잡한 기본값을 설정할 수 있습니다.
모든 액세스 컨트롤러를 통과하도록 요청하면 해당 API 개체가 검사 루틴에 의해 검사되고 개체 저장소에 기록됩니다 (4 단계 참조).
모든 Kubernetes 클러스터에는 일반 사용자와 Kubernetes 가 관리하는 서비스 계정의 두 가지 유형의 사용자가 있습니다.
Kubernetes 에는 일반 사용자 계정을 나타내는 개체가 없습니다. 일반 사용자 정보는 API 호출을 통해 클러스터에 추가할 수 없습니다.
그러나 Kubernetes 는 여전히 클러스터의 인증 기관이 서명한 합법적인 인증서를 제공할 수 있는 사용자가 인증된 사용자라고 생각합니다. 이 구성을 기반으로 Kubernetes 는 인증서에 있는 "subject" 의 일반 이름 필드 (예: "/CN=bob") 를 사용하여 사용자 이름을 결정합니다. 그런 다음 역할 기반 액세스 제어 (RBAC) 하위 시스템은 사용자가 자원에 대해 특정 작업을 수행할 수 있는지 여부를 결정합니다.
일반 사용자와 달리 서비스 계정은 Kubernetes API 가 관리하는 사용자입니다. 이들은 특정 네임스페이스에 바인딩되거나, API 서버에 의해 자동으로 작성되거나, API 호출을 통해 만들어집니다. 서비스 계정은 Pod 에 설치되는 비밀리에 저장된 자격 증명 세트와 연결되어 클러스터의 프로세스가 Kubernetes API 에 액세스할 수 있도록 합니다.
Kubernetes 는 인증 플러그인을 사용하여 클라이언트 인증서, 호스팅 토큰, 인증 에이전트 또는 HTTP 기본 인증 메커니즘을 사용하여 API 요청의 id 를 확인합니다. HTTP 요청이 API 서버로 전송되면 플러그인은 다음 속성을 요청 자체와 연관시킵니다.
여러 인증 방법을 동시에 활성화할 수 있습니다. 일반적으로 최소한 두 가지 방법을 사용합니다.
클러스터에서 여러 인증 모듈이 활성화된 경우 인증 완료를 성공적으로 요청한 첫 번째 모듈은 직접 평가 결정을 내립니다. API 서버는 인증 모듈의 실행 순서를 보장하지 않습니다.
클라이언트 인증서 인증을 시작하려면 apiserver 를 구성하고 -client-ca-file = somefile 매개 변수를 전달해야 합니다. 여기서 ca 는 클러스터의 ca 와 일치해야 합니다. 다음 명령을 사용하여 클러스터에서 사용하는 ca 를 볼 수 있습니다.
클라이언트의 인증서가 인증을 통과하면 주제의 공용 이름이 요청된 사용자 이름으로 사용됩니다. Kubernetes 1.4 부터 클라이언트 인증서는 인증서의 조직 필드를 통해 사용자의 그룹 구성원 정보를 나타낼 수도 있습니다. 사용자에 대한 여러 그룹 구성원 정보를 포함하려면 인증서 유형에 여러 조직 필드를 포함할 수 있습니다.
API 서버의 명령줄 설정 -token-auth-file = somefile 옵션을 설정하면 파일에서 holder 토큰을 읽습니다. 현재 토큰은 장기간 유효하므로 API 서버를 다시 시작하지 않으면 토큰 목록을 변경할 수 없습니다.
토큰 파일은 최소한 세 개의 열 (토큰, 사용자 이름 및 사용자의 UID) 을 포함하는 CSV 파일입니다. 나머지 열은 선택적 그룹 이름으로 간주됩니다.
서비스 계정은 서명된 소유자 토큰을 사용하여 요청을 검증하는 자동 활성화된 사용자 인증 메커니즘입니다.
서비스 계정을 만들 때 k8s 는 인증에 사용할 수 있는 토큰을 포함하는 적절한 비밀을 자동으로 생성합니다.
위의 토큰은 인증에 사용할 수 있습니다.
인증을 위해 token 을 사용하는 모든 요청에는 Authorization 의 HTTP 요청 헤더가 있어야 하며 값 형식은 Bearer TOKEN 입니다.
예를 들어 소유자 토큰이 31ada4fd-adec-460c-809a-9e56 ceb75269 인 경우 HTTP 헤더에 다음과 같이 나타납니다.
이 인증 방법을 사용하면 apiserver 가 요청 헤더에서 사용자 정보를 가져옵니다. 인증 프로세스는 그림과 같습니다.
이 인증 방법을 사용하려면 apiserver 를 다음과 같이 구성해야 합니다.
예:
Apiserver 가 다음과 같이 구성되어 있다고 가정합니다
수신된 요청 헤더는 다음과 같습니다
인증에 대해 다음 사용자 정보가 생성됩니다
역할은 항상 네임 스페이스에서 액세스 권한을 설정하는 데 사용됩니다. 역할을 만들 때 역할이 속한 네임스페이스를 지정해야 합니다.
대신 클러스터 role 은 클러스터 전체 리소스입니다. Kubernetes 객체는 네임스페이스 범위이거나 클러스터 범위이고 둘 다 아니기 때문에 두 리소스의 이름은 다릅니다 (Role 과 ClusterRole).
클러스터 롤은 여러 가지 용도로 사용됩니다. 이 대화상자를 사용하여 다음을 수행할 수 있습니다.
네임스페이스에 역할을 정의하려면 role； 을 사용해야 합니다. 클러스터 전체 역할을 정의하려면 ClusterRole 을 사용해야 합니다.
역할 예
ClusterRole 예
역할 바인딩은 사용자 또는 사용자 그룹에 역할에 정의된 권한을 부여하는 것입니다. 여기에는 여러 주제 (사용자, 그룹 또는 서비스 계정) 목록과 해당 주제에서 얻은 역할에 대한 참조가 포함되어 있습니다. RoleBinding 은 지정된 네임스페이스에서 권한 부여를 수행하고 ClusterRoleBinding 은 클러스터 전체 권한 부여를 수행합니다.
RoleBinding 은 동일한 네임스페이스에 있는 모든 역할을 참조할 수 있습니다. 또는 RoleBinding 은 ClusterRole 을 참조하고 ClusterRole 을 RoleBinding 이 있는 네임스페이스에 바인딩할 수 있습니다. 클러스터 역할을 클러스터의 모든 네임스페이스에 바인딩하려면 ClusterRoleBinding 을 사용해야 합니다.
역할 바인딩 예
샘플 ClusterRoleBinding
다음은 RBAC 인증에 대한 개요입니다. 요약하면, 역할은 역할이 소유한 권한을 정의하고, 역할 바인딩은 역할을 사용자와 연결합니다. 여기서 권한은 어떤 자원에 대해 작업을 수행할 수 있는 권한이며, 사용자에게는 일반 사용자와 서비스 계정이 포함됩니다.
RBAC 에 대한 자세한 설명은 k8s 에 내장된 몇 가지 기본 역할을 포함한 공식 홈페이지를 참조하십시오.
여기서 테스트한 k8s 클러스터는 kubeadm 을 통해 설치되며, k8s 의 구성 요소 (예: kube-apiserver 및 kube-scheduler) 를 정적 pod 으로 실행합니다. 따라서 kubectl get pod 명령을 통해 해당 구성 요소의 구성을 볼 수 있습니다.
위의 결과에서 볼 수 있듯이 사용된 ca 는 /etc/kubernetes/pki/ca.crt 이며 클라이언트 인증서 생성을 시작합니다.
이렇게 하면 test 라는 클라이언트 인증서가 생성되어 이 인증서를 사용하여 k8s 의 API 를 조정합니다.
이것은 우리가 인증을 통과했지만 인증이 실패했다는 것을 의미한다. 다음으로 테스트를 승인합니다.
먼저 kube-system 네임스페이스에 pod 읽기 권한이 있는 역할 (role.yaml) 을 만들고 kubectl apply -f role.yaml 명령을 사용하여 적용합니다.
다음으로 RoleBinding 을 만들고, 테스트를 위해 새로 만든 캐릭터를 바인딩하고, kubectl apply -f bind.yaml 명령을 사용하여 적용합니다.
유효화 후 curl 로 API 를 호출하면 모든 것이 정상입니다.
먼저 다음과 같이 kube-system 아래에 서비스 계정을 생성합니다
쓸모가 있는지 보자.
테스트라는 test (서비스 계정) 가 만들어진 것을 볼 수 있습니다. 다음으로, 그의 상응하는 비밀을 검사하여 토큰을 얻는다.
토큰을 사용하여 k8s API 호출
결과에 따라 인증이 통과했음을 확인할 수 있습니다. 이제 sa 에게 bind.yaml 을 수정하도록 권한을 부여하고 다음과 같이 수정합니다.
Kubectl apply -f bind.yaml 명령이 적용된 후 API 를 다시 호출하면 403 이 반환되지 않습니다.
이전에 apiserver 의 구성을 보면 apiserver 가 프록시 인증을 켜서 사용된 ca 를 나타내는 다음과 같은 구성을 볼 수 있습니다.
다음으로 ca 에서 에이전트가 사용하는 인증서를 생성합니다. 이 ca 는 일반적으로 X509 에서 사용하는 ca 와 일치하지 않습니다.
또한 이 방법을 사용하여 API 를 호출하면 사용자마다 해당 요청 헤더만 변경하면 되고 인증서는 변경할 필요가 없습니다. X509 방법을 사용하는 경우 사용자마다 다른 인증서를 사용해야 합니다.
Api 호출
여기에 사용된 요청 헤더는 현재 사용자가 test 이고 이전에 테스트가 승인되었음을 나타내기 때문에 403 을 반환하지 않습니다.
다음으로 사용자 이름을 jojo 로 변경하고 API 를 다시 호출합니다.
반환된 결과는 다음과 같습니다
다음은 사용 가능한 API 와 사용 방법을 설명하는 공식 API 참조 문서입니다.