는 Kubernetes 인증 및 권한 부여 작업의 해적 : K8S 액세스 제어 항목

는 Kubernetes 널리 사용으로 업계는 탄성 신축성 및 컨테이너는 Kubernetes와 같은 응용 프로그램의 관리가 매우 잘 알고있는 표준 컨테이너 프레임 레이아웃 관리, 많은 개발자 및 핵심 개념을 배포하는 관리자를 받아 들였다. 그리고 제작 배포, 안전에 필수적인는 Kubernetes. 따라서, 사용자 및 응용 프로그램 플랫폼 인증 및 권한 부여를 관리하는 방법을 이해하는 것이 필요하다.


우리는 플랫폼는 Kubernetes 인증 및 권한 부여 포드 외부 사용자의 내부를 이해하는 실용적인 관점에서, 기사의 시리즈를 시작합니다. 나는 허용하거나 리소스에 대한 액세스를 제한하는 역할 및 역할 바인딩을 사용하는 방법을 설명합니다.


API 서버 -는 Kubernetes 게이트웨이


API는는 Kubernetes 액세스 인터페이스를 제공하기 위해 (예 : 노드 라벨, 포드, 서비스, 배포, 비밀, configmaps 및 침입 등) 자원 객체의 모든 유형입니다. 간단한 기본 CRUD REST API를 (CRUD) 작업에 의해 실행이 자원 오브젝트.


는 Kubernetes 게이트웨이 자원 객체를 액세스하고 관리 할 수있는 유일한 입구로 핵심 빌딩 블록 중 하나는 Kubernetes의 API 서버이다. 내부 구성 요소 (예를 들어 kubelet, 스케줄러 및 제어) 서버 접속 스케줄링 및 조정을위한 API의 API. 키 / 값 데이터베이스를 분산, etcd 만 API 서버를 통해 액세스 할 수 있습니다.

16c8ddcd3bf5914c? w = 805 (H) = 536 & F = JPEG 및 S = 51,321

일반적으로 우리는 API 서버와 상호 작용하는 명령 줄 도구를 kubectl 수 있습니다. kubectl에서 전송 된 모든 내용이 결국 API 서버를 수신합니다. 따라서, 도구의 복수는 직접 또는 간접적으로 동일한 API를 사용하여 연결합니다.


심지어는 Kubernetes 클러스터의 작동 또는 액세스 개체를하기 전에, 요청이 또한 API 서버에서 인증 할 필요가있다. REST 경로 기반 TLS 프로토콜 X.509 인증서를 보호하고 트래픽을 암호화합니다. 인코딩 및 CA 인증서 및 클라이언트 인증서를 검색 할 수있는 요청 / 설정을 전송하기 전에 Kubectl 찾아보기 파일은 ~ / .kube.




apiVersion : V1 
클러스터 : 
- 클러스터 :     
    인증서 기관 : /Users/janakiramm/.minikube/ca.crt의     
    서버 : https://192.168.99.100:8443   
  이름 : minikube의 
상황 : 
- 컨텍스트 :     
    클러스터 : minikube의     
    사용자 : minikube의   
  이름 : minikube 
현재 상황을 : minikube 
종류 : 구성의 
기본 설정을 : {} 
사용자 : 
- 이름 : minikube의   
 사용자 :     
     클라이언트 인증서를 : /Users/janakiramm/.minikube/client.crt의     
     클라이언트 키 : /Users/janakiramm/.minikube/client합니다. 키



클러스터에서 사용 Ca.crt 파일은 CA 인증서 파일 client.crt을 나타내며, 사용자 minikube에 매핑 client.key. 요청의 문맥에서 사용 Kubectl 이러한 인증서와 키는 인코딩됩니다.


우리는 API 서버 curl 명령을 통해 액세스 할 수 있습니까? 대답은 '예'입니다.


심지어 가장 일반적인 작업이 kubectl 프록시를 실행하여 터널 프로토콜을 사용하는 것입니다, 우리는 여전히 컴퓨터에서 사용 가능한 경로 인증서를 통해 액세스 할 수 있습니다. CA 인증서뿐만 아니라, 우리는 머리에 base64로 인코딩 된 토큰 (토큰)를 포함해야합니다.


다음과 같이 컬 명령 토큰 (토큰) 및 API 호출을 검색하는 방법 :




kubectl의 구성도 -o jsonpath = "{"클러스터 이름 \ tServer \ n을 "{} 범위 .clusters [*]} {.} 이름 {"\의 t "{}. CLU





클러스터 이름 서버  
minikube https://192.168.99.100:8443





수출 CLUSTER_NAME = "minikube"





APISERVER = $ (kubectl의 구성도 -o jsonpath = "{. 클러스터 [? (@. 이름 == \"$ CLUSTER_NAME \ ")]. cluster.server} ')


다음으로 중요한 작업은 기본 토큰과 관련된 서비스 계정을 얻는 것입니다. 이 개체는 우리가 더 나은 기사 후 그것을 이해, 걱정하지 않아도됩니다.




TOKEN = $ (수 kubectl 비밀 -o jsonpath = "{. 항목 [? (@. metadata.annotations [ '는 Kubernetes \ .io / 서비스 -


이제 우리는 모든 데이터가 컬 호출 있습니다 :




\의 $의 APISERVER / 버전 : -X GET \ --cacert ~ / .minikube / ca.crt \ --header "무기명 $ 토큰 인증"컬


16c8de9511c0d6fd? w = 1024 H = 585 & F = JPEG 및 S = 77,860


액세스 제어의 세 단계는 Kubernetes


如上文所述,用户和Pod在访问或操作对象之前都要由API Server进行身份认证。


当一个有效的请求发送到API Server时,在它被允许或被拒绝之前将经历3个步骤。



16c8de9a07c95a12?w=1024&h=401&f=jpeg&s=27106

1、 身份认证


一旦TLS连接建立,请求就进入到身份认证阶段,在这一阶段,请求有效负载由一个或多个认证器模块检查。


认证模块时管理员在集群创建过程中配置的,一个集群可能有多个认证模块配置,每个模块会依次尝试认证, 直到其中一个认证成功。


在主流的认证模块中会包括客户端证书、密码、plain tokens、bootstrap tokens以及JWT tokens(用于service account)。客户端证书的使用是默认的并且是最常见的方案。有关认证模块的详细列表,请参阅:

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


请注意,Kubernetes是没有用于验证用户身份的典型用户数据库或者配置文件。但是它使用从X.509证书以及令牌中提取的字符串,将它们传递到身份认证模块。OpenID,Github甚至LDAP提供的外部认证机制可以通过其中一个认证模块与Kubernetes集成。


2、 授权


一旦API请求得到认证,下一步就是确认这一操作是否被允许执行。这是访问控制流程中的第二个步骤。


对于授权一个请求,Kubernetes主要关注三个方面——请求者的用户名、请求动作以及该动作影响的对象。用户名从嵌入token的头部中提取,动作是映射到CRUD操作的HTTP动词之一(如 GET、POST、PUT、DELETE),对象是其中一个有效的Kubernetes对象,如pod或者service。


Kubernetes基于一个存在策略来决定授权。默认情况下,Kubernetes遵循封闭开放的理念,这意味着需要一个明确的允许策略才可以访问资源。


마찬가지로, 인증에, 승인 ABAC 모드 모드은 webhook RBAC 모드로 구성된 하나 개 이상의 모듈들에 기초한다. 관리자가 클러스터를 만들 때, 그들은 API와 통합 인증 모듈을 절단 구성합니다. 다수의 모듈이 사용되며, 모든 모듈 요청이 승인 된 경우, 각 모듈은 인증 요청을는 Kubernetes를 체크한다. 모두의 모든 모듈이 요청을 거부하는 경우, 요청 (HTTP 상태 코드 403) 거부됩니다. 당신이 지원되는 모듈의 자세한 목록을 원하는 경우, 참조 :

https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules


당신이 kubectl의 기본 구성을 사용하는 경우, 모든 요청을 전달합니다, 그리고 따라서 때 클러스터 관리자로 간주 될 수있다. 우리는 새로운 사용자를 추가 할 때, 기본적으로 그들은 액세스를 제한합니다.


3, 허용 제어


입학 제어 요청에 의해 마지막 단계입니다. 이전 두 단계와 마찬가지로, 많은 액세스 제어 모듈이 있습니다.


차분하지만 처음 두 단계는 최종 단계는 대상물을 수정할 수 있다는 것이다. 입학 제어 모듈은, 갱신 및 연결 (프록시) 단계를 생성, 삭제하는 물체에 작용하는,하지만 읽어 개체가 포함되어 있지 않습니다. 예를 들어, 예를 들면, 수락 제어 모듈은 특정 스토리지 클래스를 사용하기 위해 지속적인 볼륨 문 (PVC)를 만들 수있는 요청을 수정하는 데 사용할 수 있습니다. 또 다른 전략은 용기 거울상 매번 생성하도록 구현 될 수있는 모듈을 추출한다. 입학 제어 모듈에 대한 자세한 내용은 다음을 참조하십시오

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


이 과정에서 두 거부 수락 제어 모듈의 경우, 그 요청은 즉시 거부됩니다. 입학 컨트롤러가 모든 요청되면, 인증 절차를 이용하여 객체에 대응하는 API는이를 확인하고, 기록 대상을 저장한다.


기사의 다음 부분에서, 우리는 더 나은 사용자가 만들고 인증을 구성 이해할 것이다. ~ 조정 요 그대로



추천

출처blog.51cto.com/12462495/2429379