150. Certificates API
사용자와 클러스터가 있는 상황이다.
나는 인증서와 키를 가지고 있다.
사용자를 추가해야한다면?
b 사용자의 인증서를 관리자한테 주고 관리자가 클러스터에 넘겨 서명을 받는다.
그리고 사용한다.
쿠버네티스 CA 서버
마스터 노드에 ca 서버가 있다면 마스터 노드 또한 ca 서버이다 ?
매번 인증서를 넘기고 서명 받는 작업을 하는 것은 귀찮다.
Certificates API 가 하는일
인증서를 건낸후 바로 서명 받고 돌려받는 것이 아니라 CSR객체를 만든다 .
객체가 생성되면 모든 유저들이 요청을 검토하고 확인할 수 있다.
1. openssl genrsa - 키생성
2. openssl req - 관리자에게 요청
3. 관리자는 서명 요청 객체 생성
요청은 베이스 64 명령어로 암호화 해야한다.
그 후 인코딩된 텍스트를 요청 필드로 옮기고 요청을 제출한다.
CSR 이 생성된다.
csr 확인하기
인증서 서명하기
csr yaml 파일을 확인하면 cert 부분은 base 64 로 암호화되어있다.
ca는 controlplane 어느부분에서 담당할까 ?
컨트롤러 매니저에서 담당한다.
controller manager 안에 csr-approving, csr-sigining 이 존재한다.
누구든 인증서에 서명하려면 CA 서버의 root 인증서와 개인키
151. Practice Test - Certificates API
1.
A new member akshay joined our team. He requires access to our cluster. The Certificate Signing Request is at the /root location.
Inspect it
csr과 key 가 있다.
2.
Create a CertificateSigningRequest object with the name akshay with the contents of the akshay.csr file
As of kubernetes 1.19, the API to use for CSR is certificates.k8s.io/v1.
Please note that an additional field called signerName should also be added when creating CSR. For client authentication to the API server we will use the built-in signer kubernetes.io/kube-apiserver-client.
Certificate Signing Requests | Kubernetes
Create CertificateSigningRequest
Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: myuser
spec:
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
signerName: kubernetes.io/kube-apiserver-client
expirationSeconds: 86400 # one day
usages:
- client auth
EOF
csr 파일의 형식과 다르다.
csr 파일을 -> base 64 로 암호화한뒤 akshay.yaml 파일의 req 부분에 복붙한다.
실행하기
3. What is the Condition of the newly created Certificate Signing Request object?
pending
4. Approve the CSR Request
요청 승인하기
5. How many CSR requests are available on the cluster?
2개
6.
During a routine check you realized that there is a new CSR request in place. What is the name of this request?
agent smith
7.
Hmmm.. You are not aware of a request coming in. What groups is this CSR requesting access to?
Check the details about the request. Preferebly in YAML.
masters 그룹에서 요청
8. That doesn't look very right. Reject that request.
k certificate deny agent-smith 로 요청 거부할 수 있다.
9. Let's get rid of it. Delete the new CSR object
153. KubeConfig
사용자가 my-kube-playground 클러스터로 인증서 요청을 날린다면
아래는 kubectl 을 이용한 요청
키, 인증서, ca
매번하면 귀찮기 때문에 kubeconfig 를 만들어서 쉽게 사용
kubeconfig file 의 경로는 $HOME/.kube/config 이다.
기본으로 설정되어있기 때문에 이때까지 생략하고 잘 쓴거
KubeConfigFile의 구성
Clusters, Contexts, Users
이 세가지 context는 어떤 유저가 어떤 클러스터에 접근할 수 있는지 명시한다.
mykubeplayground, certificate-authority 는 클러스터로 간다.
키, 인증서는 users 로 간다.
두개를 조합해서 컨텍스트를 만든다.
yaml 파일에서 확인
clusters, user, context 이렇게 되어있다.
파일은 그대로 두고 kubectl 로 실행
kubectl 은 어떤 컨텍스트를 골라야할까 ?
currentcontext를 사용해 기본 컨텍스트 정의
kubectl config
클러스터 확인 가능
현재 컨텍스트 변경하기
use context 로 컨텍스트를 변경한다.
네임스페이스 관련
네임스페이스는 클러스터 단위에서 생성된다.
컨텍스트 부분에 네임스페이스도 명시한다.
Certificates in kubeConfig
인증서 파일의 경우 전체 경로를 쓰는 것이 좋다.
ca 파일의 경우 그냥 crt 내용을 암호화해서 복붙할 수도 있다.
154. Practice Test - KubeConfig
1. Where is the default kubeconfig file located in the current environment?
Find the current home directory by looking at the HOME environment variable.
실행해보고 확인가능
/root/.kube/config
2. How many clusters are defined in the default kubeconfig file?
1개
3. How many Users are defined in the default kubeconfig file?
1개
4. How many contexts are defined in the default kubeconfig file?
1개
5. What is the user configured in the current context?
6. What is the name of the cluster configured in the default kubeconfig file?
kubernetes
7. A new kubeconfig file named my-kube-config is created. It is placed in the /root directory. How many clusters are defined in that kubeconfig file?
4개
8. How many contexts are configured in the my-kube-config file?
4개
9. What user is configured in the research context?
dev-user
10. What is the name of the client-certificate file configured for the aws-user?
11. What is the current context set to in the my-kube-config file?
12.
I would like to use the dev-user to access test-cluster-1. Set the current context to the right one so I can do that.
Once the right context is identified, use the kubectl config use-context command.
my-kubeconfig 가 기본 config 파일이 아니기 때문에 --kubeconfig 옵션이 필요하다.
13. We don't want to have to specify the kubeconfig file option on each command. Make the my-kube-config file the default kubeconfig.
파일을 기본 디렉터리로 옮긴다.
14.
With the current-context set to research, we are trying to access the cluster. However something seems to be wrong. Identify and fix the issue.
Try running the kubectl get pods command and look for the error. All users certificates are stored at /etc/kubernetes/pki/users.
developer.crt. 가 아니라 dev-user.crt 로 되어있다.
/root/.kube/config 파일을 수정하자.
157. API Groups
api 버전을 확인하고 싶다면?
master 노드 포트에 접속해서 확인가능하다.
이렇게도 접속가능하다.
api 포드에 대해 집중해보자
쿠버네티스api 는 여러종류로 나눠진다.
core api 에는 우리가 아는 중요한거 다 들어있다.
naemd api 에는 다양한 기능들이 있다.
마스터 노드 포트로 바로 접속하면 사용 가능한 api 그룹 리스트가 나온다.
인증서 없이 클러스터 api 에 접속할 수 없다.
키,인증서, ca 를 넘겨야한다.
Kubectl Proxy 로 접속하기
프록시로 접속한후 8001 포트를 통해 api 리스트를 가져올 수 있다. ( 인증서 필요 없음)
Kube proxy ≠ kubectl proxy
엄연히 다른거다.