24년 11월 이전/데브옵스(DevOps)를 위한 쿠버네티스 마스터
16. 클러스터 유지와 보안 트러블 슈팅 (2)
Gurumee
2021. 9. 8. 19:09
반응형
이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크
TLS 통신의 이해와 인증서 위치 확인
Kubernetes에서 사용자를 제어하기 위해서 TLS 통신 방식을 이용한다.
TLS는 기존 통신 계층에 대해서 조금 더 보안이 높은 통신을 위해 만들어졌다. 즉, 4계층인 Transport Layer(TCP)와 7 계층인 Application Layer(HTTP) 사이에서 동작한다. 다음과 같은 기능이 있다.
- 데이터 암호화
- 데이터 무결성
- 서버/클라이언트 인증
다음은 HTTP에 TLS 통신 방식을 곁들인 HTTPS 통신 방식의 흐름도이다.
- 서버 오픈 시, 개인 키를 생성하여
CA(Certificate Authority)에서 인증서를 발급 받는다. 이 때 공개 키도 만들어진다. - 이제 클라이언트에서 서버로 요청이 온다.
- 이 때 서버에서는 공개 키를 전달한다.
- 클라이언트는 전달 받은 공개 키가 유효한지
CA에서 확인한다. 인증이 되면 서버의 개인 키로 암호화된 "세션 키"를 발급받는다. - 그 후 클라이언트는 암호화된 세션 키를 전달한다.
- 세션 키를 받은 서버는 개인 키로 복호화 후, 유효한 키인지 확인한다. 확인이 되면 ACK 응답을 보낸다.
- 이제 암호화된 데이터 송/수신이 이루어진다.
Kubernetes 클러스터 인증서 정보 확인과 자동 갱신
이번 절은 VM에서 진행된다.
Kuberenetes의 컴포넌트들의 인증서의 위치는 다음에서 확인할 수 있다.
$ sudo ls -al /etc/kubernetes/pki
total 72
drwxr-xr-x 3 root root 4096 9월 1 21:37 .
drwxr-xr-x 4 root root 4096 7월 3 18:50 ..
-rw-r--r-- 1 root root 1281 7월 3 18:50 apiserver.crt
-rw-r--r-- 1 root root 1155 7월 3 18:50 apiserver-etcd-client.crt
-rw------- 1 root root 1679 7월 3 18:50 apiserver-etcd-client.key
-rw------- 1 root root 1675 7월 3 18:50 apiserver.key
-rw-r--r-- 1 root root 1164 7월 3 18:50 apiserver-kubelet-client.crt
-rw------- 1 root root 1679 7월 3 18:50 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1066 7월 3 18:50 ca.crt
-rw------- 1 root root 1679 7월 3 18:50 ca.key
drwxr-xr-x 2 root root 4096 7월 3 18:50 etcd
-rw-r--r-- 1 root root 1078 7월 3 18:50 front-proxy-ca.crt
-rw------- 1 root root 1679 7월 3 18:50 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 7월 3 18:50 front-proxy-client.crt
-rw------- 1 root root 1675 7월 3 18:50 front-proxy-client.key
-rw------- 1 root root 1675 7월 3 18:50 sa.key
-rw------- 1 root root 451 7월 3 18:50 sa.pub
-rw-r--r-- 1 root root 101 9월 1 21:37 token.csvetcd의 인증서는 다음에서 확인할 수 있다.
$ sudo ls -al /etc/kubernetes/pki/etcd
total 40
drwxr-xr-x 2 root root 4096 7월 3 18:50 .
drwxr-xr-x 3 root root 4096 9월 1 21:37 ..
-rw-r--r-- 1 root root 1058 7월 3 18:50 ca.crt
-rw------- 1 root root 1675 7월 3 18:50 ca.key
-rw-r--r-- 1 root root 1159 7월 3 18:50 healthcheck-client.crt
-rw------- 1 root root 1675 7월 3 18:50 healthcheck-client.key
-rw-r--r-- 1 root root 1192 7월 3 18:50 peer.crt
-rw------- 1 root root 1675 7월 3 18:50 peer.key
-rw-r--r-- 1 root root 1192 7월 3 18:50 server.crt
-rw------- 1 root root 1679 7월 3 18:50 server.key이제 다음 명령어를 입력해서 apiserver-etcd-client의 인증서 정보를 확인해보자.
$ sudo openssl x509 -in /etc/kubernetes/pki/apiserver-etcd-client.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3420255542562728634 (0x2f77304b6f832aba)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = etcd-ca
Validity
Not Before: Jul 3 09:50:42 2021 GMT
Not After : Sep 6 23:27:47 2022 GMT
Subject: O = system:masters, CN = kube-apiserver-etcd-client
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ae:c3:ba:41:42:e6:6c:83:7a:dd:48:6a:db:53:
a3:fa:be:53:32:13:6f:0f:79:85:7c:59:df:6a:d0:
af:d3:9c:b0:a1:de:0b:e6:76:5f:2f:8d:55:54:b3:
65:17:74:99:2c:87:71:22:3e:0c:60:63:2b:b2:c8:
27:9e:47:cf:bc:e5:f1:d3:8a:a6:b2:06:a6:5f:36:
24:cd:71:de:73:1c:68:d3:39:4f:7e:48:8b:ea:17:
19:6e:cc:ba:56:22:3b:4e:eb:c5:58:96:88:e1:e3:
00:be:8e:58:e8:2e:c3:da:97:26:19:00:b7:f2:ae:
6e:e6:26:78:c4:ce:8a:27:c0:94:eb:06:05:dd:c9:
f6:fa:20:d4:7b:9a:7c:9a:8d:8c:8f:02:cc:c8:4b:
88:93:8f:f7:74:49:0c:a5:a3:0d:8b:7f:7b:97:7c:
87:97:b3:4c:38:e3:be:22:cf:ea:d6:ad:56:3d:68:
84:7c:a4:6c:ca:4a:9f:e2:84:60:3c:bb:b1:7b:78:
6b:a7:57:41:49:24:00:49:f9:2c:53:48:27:b8:03:
9e:0c:45:e0:b0:71:a2:b5:ef:27:ea:73:42:e2:34:
73:40:7b:db:88:fa:c1:0d:71:ce:11:2a:fb:5f:1f:
06:d5:b5:72:71:3a:05:72:25:bc:7d:a1:4e:12:7c:
d4:f3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:71:EC:FC:4E:F4:1A:B0:A2:94:0A:84:83:0B:C1:8B:30:96:A2:79:6B
Signature Algorithm: sha256WithRSAEncryption
24:da:bf:53:86:fd:85:be:a9:ff:ab:77:4d:99:e7:3a:ab:7e:
6b:cb:45:9b:f8:62:b5:bf:fb:cf:d6:63:69:f7:fd:92:8c:5f:
e9:62:e1:96:92:d7:6e:fa:44:cb:bb:53:bd:aa:11:ca:7f:d2:
8d:31:88:3b:96:5a:94:ee:94:cc:da:89:e5:9b:21:64:36:7e:
7f:22:8b:34:6b:e5:74:a7:e7:ba:0d:1a:a6:8b:70:97:33:31:
85:2f:01:86:87:a4:2e:80:58:0e:ee:00:82:38:32:4a:59:f2:
20:45:4a:b4:6d:62:3c:2c:19:c0:29:9f:fd:a4:1b:94:f8:e1:
b6:52:27:d1:e8:fe:76:fd:39:32:92:7c:7e:53:91:e6:a1:41:
00:e3:84:4e:45:4a:cb:3d:f0:bb:1d:d2:c8:89:5c:6d:33:57:
d3:3f:fa:6d:ad:10:1e:bd:26:e4:36:75:7f:91:13:7c:f1:6c:
5e:c3:92:24:18:38:da:e6:b3:00:99:91:75:5a:31:a2:ec:93:
9a:57:80:e6:36:d7:ba:25:cb:f8:04:7d:12:02:5d:00:d3:5d:
6e:b4:f3:57:fe:b4:c2:05:c9:87:92:4f:5e:c3:0b:21:5d:c8:
ea:de:14:b2:0d:16:8d:0e:ab:82:c5:d2:15:47:7e:1a:50:71:
a6:64:26:ff
-----BEGIN CERTIFICATE-----
MIIDKDCCAhCgAwIBAgIIL3cwS2+DKrowDQYJKoZIhvcNAQELBQAwEjEQMA4GA1UE
AxMHZXRjZC1jYTAeFw0yMTA3MDMwOTUwNDJaFw0yMjA5MDYyMzI3NDdaMD4xFzAV
BgNVBAoTDnN5c3RlbTptYXN0ZXJzMSMwIQYDVQQDExprdWJlLWFwaXNlcnZlci1l
dGNkLWNsaWVudDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7DukFC
5myDet1IattTo/q+UzITbw95hXxZ32rQr9OcsKHeC+Z2Xy+NVVSzZRd0mSyHcSI+
DGBjK7LIJ55Hz7zl8dOKprIGpl82JM1x3nMcaNM5T35Ii+oXGW7MulYiO07rxViW
iOHjAL6OWOguw9qXJhkAt/KubuYmeMTOiifAlOsGBd3J9vog1HuafJqNjI8CzMhL
iJOP93RJDKWjDYt/e5d8h5ezTDjjviLP6tatVj1ohHykbMpKn+KEYDy7sXt4a6dX
QUkkAEn5LFNIJ7gDngxF4LBxorXvJ+pzQuI0c0B724j6wQ1xzhEq+18fBtW1cnE6
BXIlvH2hThJ81PMCAwEAAaNWMFQwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUcez8TvQasKKUCoSD
C8GLMJaieWswDQYJKoZIhvcNAQELBQADggEBACTav1OG/YW+qf+rd02Z5zqrfmvL
RZv4YrW/+8/WY2n3/ZKMX+li4ZaS1276RMu7U72qEcp/0o0xiDuWWpTulMzaieWb
IWQ2fn8iizRr5XSn57oNGqaLcJczMYUvAYaHpC6AWA7uAII4MkpZ8iBFSrRtYjws
GcApn/2kG5T44bZSJ9Ho/nb9OTKSfH5TkeahQQDjhE5FSss98Lsd0siJXG0zV9M/
+m2tEB69JuQ2dX+RE3zxbF7DkiQYONrmswCZkXVaMaLsk5pXgOY217oly/gEfRIC
XQDTXW6081f+tMIFyYeST17DCyFdyOreFLINFo0Oq4LF0hVHfhpQcaZkJv8=
-----END CERTIFICATE-----확인해야할 양이 너무 길다. 몇 개만 간추려서 확인해보자. 여기서 Issuer를 확인하면 누구한테 인증되었는지 확인할 수 있다.
$ sudo openssl x509 -in /etc/kubernetes/pki/apiserver-etcd-client.crt -text | grep "Issuer"
Issuer: CN = etcd-caSubject를 확인하면 누가 인증을 받았는지 확인할 수 있다.
$ sudo openssl x509 -in /etc/kubernetes/pki/apiserver-etcd-client.crt -text | grep "Subject"
Subject: O = system:masters, CN = kube-apiserver-etcd-client
...여기서 O는 기관 명, CN은 인증을 받은 주체를 의미한다. 또한, Validity 밑에 Not *로 유효기간을 확인할 수 있다.
$ sudo openssl x509 -in /etc/kubernetes/pki/apiserver-etcd-client.crt -text | grep "Not"
Not Before: Jul 3 09:50:42 2021 GMT
Not After : Sep 6 23:27:47 2022 GMT
위 인증서는 즉 2021년 7월 3일 09:50:42 부터 2022년 9월 6일 23:27:47까지 유효하다. 이제 갱신을 해보자. 먼저 다음 명령어를 통해서 클러스터 내 모든 인증서들의 유효기간을 확인할 수 있다.
$ sudo kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Jul 03, 2022 09:50 UTC 299d no
apiserver Jul 03, 2022 09:50 UTC 299d ca no
apiserver-etcd-client Jul 03, 2022 09:50 UTC 299d etcd-ca no
apiserver-kubelet-client Jul 03, 2022 09:50 UTC 299d ca no
controller-manager.conf Jul 03, 2022 09:50 UTC 299d no
etcd-healthcheck-client Jul 03, 2022 09:50 UTC 299d etcd-ca no
etcd-peer Jul 03, 2022 09:50 UTC 299d etcd-ca no
etcd-server Jul 03, 2022 09:50 UTC 299d etcd-ca no
front-proxy-client Jul 03, 2022 09:50 UTC 299d front-proxy-ca no
scheduler.conf Jul 03, 2022 09:50 UTC 299d no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Jul 01, 2031 09:50 UTC 9y no
etcd-ca Jul 01, 2031 09:50 UTC 9y no
front-proxy-ca Jul 01, 2031 09:50 UTC 9y no 대부분의 인증서는 1년 정도 유효 기간이 주어지는데, 쉽게 업데이트를 하려면 클러스터를 업데이트 하면 된다. 그러면 인증서들이 모두 자동 갱신된다. 만약 수동으로 갱신해야 한다면, 터미널에 다음을 입력하면 된다.
$ sudo kubeadm certs renew all
[renew] Reading configuration from the cluster...
[renew] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed
Done renewing certificates. You must restart the kube-apiserver, kube-controller-manager, kube-scheduler and etcd, so that they can use the new certificates그럼 모든 인증서가 갱신된다. 한 번 확인해보면, 이전과 달리 364d로 유효 기간이 늘어난 것을 확인할 수 있다.
$ sudo kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Sep 06, 2022 23:27 UTC 364d no
apiserver Sep 06, 2022 23:27 UTC 364d ca no
apiserver-etcd-client Sep 06, 2022 23:27 UTC 364d etcd-ca no
apiserver-kubelet-client Sep 06, 2022 23:27 UTC 364d ca no
controller-manager.conf Sep 06, 2022 23:27 UTC 364d no
etcd-healthcheck-client Sep 06, 2022 23:27 UTC 364d etcd-ca no
etcd-peer Sep 06, 2022 23:27 UTC 364d etcd-ca no
etcd-server Sep 06, 2022 23:27 UTC 364d etcd-ca no
front-proxy-client Sep 06, 2022 23:27 UTC 364d front-proxy-ca no
scheduler.conf Sep 06, 2022 23:27 UTC 364d no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Jul 01, 2031 09:50 UTC 9y no
etcd-ca Jul 01, 2031 09:50 UTC 9y no
front-proxy-ca Jul 01, 2031 09:50 UTC 9y no TLS 인증서를 활용한 유저 생성
이번엔 TLS 인증서를 이용해서 유저를 생성할 수 있다. 먼저 개인 키를 생성해야 한다. 터미널에 다음을 입력한다.
$ openssl genrsa -out gurumee.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
...................+++++
......................................+++++
e is 65537 (0x010001)이러면 gurumee.key라는 개인 키가 생성된다. 그 후 개인 키를 기반으로 인증서 서명을 요청할 수 있다. 터미널에 다음을 입력한다.
$ openssl req -new -key gurumee.key -out gurumee.csr -subj="/CN=gurumee/O=inflearn-k8s"그러면 guruemee.csr이 생성된다. 그 후 CA기관, 여기서는 마스터 서버에 인증서 요청을 할 수 있다.
$ sudo openssl x509 -req -in gurumee.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out gurumee.crt -days 500
Signature ok
subject=CN = gurumee, O = inflearn-k8s
Getting CA Private Key이제 gurumee.crt까지 만들어졌다. 이제 만든 crt와 key를 기반으로 유저를 생성하면 된다.
$ kubectl config set-credentials gurumee --client-certificate=./gurumee.crt --client-key=./gurumee.key
User "gurumee" set.그 후 유저 컨텍스트를 생성한다.
$ kubectl config set-context gurumee-context --cluster=kubernetes --namespace=office --user=gurumee
Context "gurumee-context" created.이제 이 컨텍스트를 기반으로 명령어를 실행해보자.
$ kubectl get pod --context gurumee-context
Error from server (Forbidden): pods is forbidden: User "gurumee" cannot list resource "pods" in API group "" in the namespace "office"이 유저는 Pod 목록을 읽을 권한이 없기 때문에 위에 에러는 유효한 에러이다.
RBAC
RBAC는 유저에게 kubernetes 클러스터가 관리하는 리소스들에 대한 접근 제어를 가능하게 해준다. Role단위로 접근 권한을 생성하며 RoleBinding으로 생성한 Role을 유저에게 부여할 수 있다.
AWS를 빗대어서 표현하자면 Policy는 Role, 유저는 유저, 그리고 유저에 Policy를 할당하는 과정을 RoleBinding이라고 보면 된다. RBAC는 다음과 같이 총 4개의 리소스가 있다.
- Role
- RoleBinding
- ClusterRole
- ClusterRoleBinding
Role, RoleBinding은 네임스페이스에 종속적이다. 반면에 ClusterRole, ClusterRoleBinding 네임스페이스에 종속적이지 않으며 클러스터 전체에 영향을 줄 수 있다. 따라서 보통 다음과 같이 권한을 부여하는 편이다.
- User(Developer), ServiceAccount: Role, RoleBinding
- User(Admin): ClusterRole, ClusterRoleBinding
이제 한 번 Role과 RoleBinding을 생성해보자. 위의 절에서 만든 유저에 대해서 office 네임스페이스에서 Pod, Deployment, ReplicaSet을 만들고 조회할 수 있는 권한을 부여할 것이다. 먼저 Role을 다음과 같이 생성한다.
src/ch16/k8s/rbac-deployment-manager.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: office
name: deployment-manager
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["pods", "deployments", "replicasets"]
verbs: ["get", "watch", "list", "create", "update", "patch", "delete"],
---
# RoleBinding
# ...그 후, 유저에게 Role을 부여하는 RoleBinding을 생성한다.
src/ch16/k8s/rbac-deployment-manager.yaml
# Role
# ...
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: deploy-manager
namespace: office
subjects:
- kind: User
name: gurumee
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: deployment-manager
apiGroup: rbac.authorization.k8s.io그리고 생성한다. 이 때 Namespace인 office와 유저인 gurumee는 미리 생성되어 있어야 한다.
$ kubectl create -f rbac-deployment-manager.yaml
role.rbac.authorization.k8s.io/deployment-manager created
rolebinding.rbac.authorization.k8s.io/deploy-manager created그 후, gurumee-context로 Pod을 조회할 수 있다.
$ kubectl get pod --context gurumee-context
No resources found in office namespace.또한 조회 뿐 아니라, 생성, 삭제, 업데이트도 가능하다. 물론 Deployment, ReplicaSet도 가능하다.
Kubectl Config 더 깊이!
사실, 이런식으로 api-server에 리소스 요청이 가능하다.
$ curl https://kube-api-server:6443/api/v1/pods\
--key user.key
--cert user.crt # cluster, user 위한 정보
--cacert ca.crt 하지만 이렇게 하기는 매우 불편하기 때문에, kubectl이라는 클라이언트를 통해서 리소스 요청을 한다.
$ kubectl get pod이런 리소스를 요청하기 위해서는 유저와 컨텍스트, 그리고 RBAC가 적절히 생성되어야 한다. 여태까지 설정한 config는 다음 명령어로 확인이 가능하다.
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED # kubernetes-admin crt 암호화
server: https://10.0.2.15:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
namespace: office
user: gurumee
name: gurumee-context
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
- context:
cluster: kubernetes
namespace: frontend
user: user1
name: user1-context
current-context: kubernetes-admin@kubernetes # 현재 사용중인 쿠버네티스 계정
kind: Config
preferences: {}
users:
- name: gurumee
user:
client-certificate: /home/gurumee/k8s-master/ch16/gurumee.crt
client-key: /home/gurumee/k8s-master/ch16/gurumee.key
- name: kubernetes-admin
user:
client-certificate-data: REDACTED # kubernetes-admin crt 암호화
client-key-data: REDACTED # kubernetes-admin key 암호화
- name: user1
user:
token: REDACTED만약 위 내용을 평문으로 보고 싶다면 다음 명령어를 입력하면 된다.
$ cat ~/.kube/config
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1EY3dNekE1TlRBME1Wb1hEVE14TURjd01UQTVOVEEwTVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTm1ICkZUVnN4SGdQWEtKT29ybkJGNXd6L25Cb2NwdmR4Qlo1Snd5eVZLWHU5b1Q5VFhDY1FBR3dNTFFOOURCZ2NnMDIKMmEvTE1rd2RkVDdTZS8wazB1TngxcDJidzFlMlFjVU5tUkt5S2o0VUdvS28raXBzZ1BzeU1xRCt3aVpCUkNCegpaeVV3MHFkTmZFOFJwVDRIcFJtd0hJZ2lzZWdRYUZ3Q0x2M3dtbHV1RGg3TzBUYktkMmxZcVJvdS9teWwzV21RCitCSG1ZSmxMayt4Vk1QNEorM05URTdJVXNpNWVHYnNYanJhcmZmYUVLWTdMUWd1aHVKNFdlZ3NvQmFjVW1VWmIKZVdLU0dxdllwa3NsT2tiSGNyUVlsNUF3QlNzcmg0YlVaelQ4bFBOVGk3NW0zaHU4NnZ1L3lDM2FNZ2tXS0w5bAphZFYyTU04VTZxa2h6dzRjY2xFQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZMeEd4YXd6Uk1jNnFZSmhtazZyR1JPUHZUSzFNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFDV2xVZEZyNTZ6alFiOVFhTnJqYXRCUHJGQ0FZRGNaSysvWjVKd2p2cWZCL21xeERkOQpDNFhTSEVoa3o1VDV1cjFUdXJYSFE1Z2FqaldEWnJhMGoxZEVjVysrYWV2a3J5VXloazUyaHlVd1lVckRzempGCkpnQXY3bXR5N0xiQXZXOU1kK3BsbkFjejhFSVlUOWlCaUpaVU1qeHJFTWNWNWpnaHczSDgrNmVrZURRMHFROHQKOU9hdGMrbzZhU0pLMi81RG1BSjFqQ2krNUZyNDZiaDNyWjRLNHdtU3h4RG1UWGpNaStYSndSQ1drMFFldzdrcQpnaUVZWEtkSmliV2Q2YndxSFBrd0RrMEd3N09TMXMyblEyVGhZdGpkajZlMit3cEdTemwxTHEzZm83Z2s1N3g2CmNrWE5MOFh0OXdMbW1VSmc5Q29vUy82WUdHcXk2ZTZQLy9BMAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://10.0.2.15:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
namespace: office
user: gurumee
name: gurumee-context
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
- context:
cluster: kubernetes
namespace: frontend
user: user1
name: user1-context
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: gurumee
user:
client-certificate: /home/gurumee/k8s-master/ch16/gurumee.crt
client-key: /home/gurumee/k8s-master/ch16/gurumee.key
- name: kubernetes-admin
user:
client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJVUIxeDZVQXl4WFl3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRBM01ETXdPVFV3TkRGYUZ3MHlNakEzTURNd09UVXdORE5hTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXhtclI1aUZIai8ycHVSbGwKUjdobzRnUU1XUmd2RXNCcXRKNjljaUtJUGZUVFNadTRObW5TMDdnODV4dTE4K3NHN0h6Z3FpY0ZkdUdxWFNIUgpDNUVhbFg4ekRJZ01jV1YwNnNkUWl1TWNKNUFDSUVLK2dMVWRJTUVDLytGYWxKQ1pvZ2RFVmpSRGJPQ0NtNU0vCmMzYk9xcjRUaWlSWFdjSGxNdkJ0bHI5SWdSZ2R2QXNxMzBkdUhkZnJuYWoxV3Z1OTJqUU8zUzJOMDZBM3R4Y1EKME9CQzhCTHFESjBLN0p3ZHJFTVljSXhBZzdiMWpLS09LcHZQdk1hQXhmL2FLRFpKTUNMQ1N2dUdPeFZOSmFMMwpaY1ovcThmUzBRRmJXV3JCakpkUi9ESU5QVWc2NDFFUzNadnFmNGhSMXVjT3VOUi85VWo1TndOY25YWDlHMnNLCkI2dGdpUUlEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JTOFJzV3NNMFRIT3FtQ1lacE9xeGtUajcweQp0VEFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBSXhoNWpWUUFIbXp3ZjlzU3VzRXE2WGZqZ2hZN2NCMDNFSFRpCnU3N0hmeFVyTGRBWitEQXRrTFRrMzEwNkZvMFk3bFJrazRiSWxDN25FTzJKeWNSeWZvdkR2K1VlSElNbG4zbloKMjZtdncwcmRHWTVhUkJkWmE3Q3RCSGR0QVdvNEtkMmxqUjQzZlo3emtYVTRablNQOStSQkhmR3lOdTFneWtWYwpjaTNBaFJ3ZDhkSzNVY0RmQWJEQVB5RWQ4c0t2cDBidE9vbWd0d1lHNHBpSWpHSXFXN2lrSXRoei9kMXZ0S3pSCnN2c1VaMzE3ZzVGa3I0Zm90Q2VZblhwcHpNR1JtNXNCMkJqZlRlSmFnREptTSt5eVBXSTRXVGt0VmxqUndZL1kKaVVvOUxWSnBNNTZHdmNpcUlPdWZRQTl0Rjh5aEhuU0psUFpuUGNEOFdVM3hHNTIxUnc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBeG1yUjVpRkhqLzJwdVJsbFI3aG80Z1FNV1JndkVzQnF0SjY5Y2lLSVBmVFRTWnU0Ck5tblMwN2c4NXh1MTgrc0c3SHpncWljRmR1R3FYU0hSQzVFYWxYOHpESWdNY1dWMDZzZFFpdU1jSjVBQ0lFSysKZ0xVZElNRUMvK0ZhbEpDWm9nZEVWalJEYk9DQ201TS9jM2JPcXI0VGlpUlhXY0hsTXZCdGxyOUlnUmdkdkFzcQozMGR1SGRmcm5hajFXdnU5MmpRTzNTMk4wNkEzdHhjUTBPQkM4QkxxREowSzdKd2RyRU1ZY0l4QWc3YjFqS0tPCktwdlB2TWFBeGYvYUtEWkpNQ0xDU3Z1R094Vk5KYUwzWmNaL3E4ZlMwUUZiV1dyQmpKZFIvRElOUFVnNjQxRVMKM1p2cWY0aFIxdWNPdU5SLzlVajVOd05jblhYOUcyc0tCNnRnaVFJREFRQUJBb0lCQUZwYmlPenBHT0xNM0w3TApmdUR6Yk9nSWVlc1U1VkwveDFncnRoQkZBNUJiYnVEbGhqVlphY1k2NzVrN2VGZjFIdmtSUVdxYlRKUy8zY3A5CnZPb3NrVk9sVW9VUmE4RTBOOU0zSTBtc2RVVGJBdXpZR0ZNYXA0SWtBNDZ0ZkllTmRqbGdYOUYyQ1lLS2wwL3IKOVloS2dZRW1BRlgzaU1QNlZic2wzSEk2OS9TNVRrUGN0WUkxazBTcXNIK1lUVS9EOTgvODluMndUeFV2Znl3VQpFTkJGZ0Z2cG9NRVBhRU42djdKa0YyNGRSUUZVMHRWdzRyQjhlT0NVMWl5UWdyc1pVeHlydVpOOXowQVdKMGJKCm9VVCs3WUthK1pFeko3aEU2OEJVNVJiZW5YVitDeWFWSXdlWUhtUWIzVjB1eUZ0dE94V0lYWVNQek1CVmZ4TmsKQkNsU1kxRUNnWUVBMXBDeEJySms1QjdyM21TeEZ1M1o1MUNhNFJuSzk4NFRxWVh2clF5cXE5TDArcnhVaEMrLwpZRDNFbFJRanpVUTNwVzMyZTRjdUJFK3JReHBPT1RTQ0NPZ0VVN3Bpc1c5WmZpREl3L3Vwa1VPYUw1TFRHckNuCkV4VDMybThhNUQwU0p4TFIxT0JOK0hsVDF0MGVGc2V5Uit2aDlFN05GMDNPYk5xZ0hqaEJjTjBDZ1lFQTdMdlYKbEVCcVh1SG5mS2NCQ2dhaXExM1dUSXIyaVFvWlMySmpOZy9Udysyc2p1dXU2QWoyakhHR0gzK0pPNkpMMGVXOApja2piS0JUZTNXcmJySUEyMFh2MnJsSVduYnBybzRvU21URUpId01OVzhXOFZWN2hLOXBzWC9rakdQRktWME9ECkpmYzlJaUpqazRIazJZN2ZJeVRDNHFnNmc1VndzRkU4Ti9XdXZaMENnWUVBeC9uNUZBM0dYSnE1S1FCZDBNb0QKOGtRODVabWRneEl0WHkxMnNhbUJsRDA4bUVoWTJRNkxaazZMWG9weng4ZFJ1YnhnSXNkZHl5VFpzT1BlamhCegpOWXZSSkp3dGljUUcrN2ZnaGxDU3ZOSHQ3WE1Cai9tZTdmajMvRHpiS21nRStDZmhLMitYSEFNd2NheUtjNTdSCmVaak9jbDNUWm1uYy83VlAwSHFMKzMwQ2dZRUE0Q3ExZ2Q3Rld2ZDdaalFWN2RKK3N0cjJsQ0I2ZHlYUzhlbEcKbk9pNzFDbjVYcFNhV1Nvem5LWGJKWFIxRkwwSUlzZnlmQjIxT08wYVpIeE5hN2sxTDRTOUFEREhMYkJiUU03Nwo4WWZYWlVCVW8vUkg5R2NWdlpybFNMUDNvaVRLQ252cGNrZjk0WmJDeCtrV05WVHV3cTZLeEdvY2pvRXg1aVBtCmErNysrcGtDZ1lFQXVIRnpFZzNpL3BPQjI3cVRyYlI2dDR1UjgzNFpieUNGb1J4cG5qYUViNUt6NlU2ZGo4SncKMGZ6RVpjU2E2U1BPcTBCRUJVUGh5cFY5d3NHTmU2WWhrRjVlZDd3ZFBQYWdPVHUxOXBuYTIxZ2hCa2tvbmV1MgpxN0R3dWpja1FYUTR6TGRaMkMrZDh0SGpKQWdtTmc0ZG5qVDVXSmkrZmI1S0hwVFR0MVdKakprPQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
- name: user1
user:
token: password1참고적으로 사용자를 바꾸는 명령어는 다음과 같다.
$ kubectl config use-context <바꾸고 싶은 user context>728x90
반응형