ノードのメタデータ保護の必要性 攻撃者からコントロールプレーンにアクセスされ、ノードに関する情報(IPアドレス、ホスト名等)を取得されないために必要。主にNetworkPolicyやClusterRoleによって保護する。 NetworkPolicyの例 コントロールプレーンのIPアドレス取得 kubectl get node controlplane -o jsonpath="{.status.addresses[0].address}" Podからコントロールプレーンへのアクセスを拒否し、メタデータの取得を防ぐ apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-metadata namespace: default spec: podSelector: matchLabels: app: app policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - <controlplane-ip>/32 # Replace with the actual IP address of the controlplane node RBAC(ClusterRole/ClusterRolebinding)の例 特定のユーザやServiceAccoutのみノード状態が見られるようにする。これにより不正なノードのメタデータの不正取得を防ぐ。 kubectl create clusterrole node-viewer --verb=get --verb=list --verb=watch --resource=nodes mTLS (相互TLS認証) Istioの導入等が有効 参考文献 https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

学習内容：LightingLabs,Certificate,CSR,kubeconfig,NetworkPolicy,Kubernetes Enviroment 成果：LightingLabs 100点 メモ： -o=jsonpathや-o=custom-columnsを指定する際、itemsから書かないこと。.specや.metadata.nameから書くこと https://kubernetes.io/docs/reference/kubectl/cheatsheet/#formatting-output K8Sのアップグレード、kubectl cordonしたらkubectl uncordonを忘れずに実施すること kubectl drain でpod排出 kubectl cordonでスケジュールさせない kubeadm,kubelet,kubectlをバージョン指定でaptで持ってくる コントロールプレーンではsudo kubeadm upgrade apply <バージョン> ワーカーノードではsudo kubeadm upgrade node kubeletを再起動 kubectl uncordonでスケジュールさせる https://v1-26.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ .crtを見たいとき openssl x509 -in server.crt -text -noout https://qiita.com/takech9203/items/5206f8e2572e95209bbc kubeconfigは.kube/configになくても接続可能 kubectl config --kubeconfig=<ファイル名> <context> https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts ip route showでデフォルトゲートウェイを確認

学習内容：Mock Exam 1,2,3 点数： Mock Exam1 94,Mock Exam2 70,MockExam3 54 良かったところ： kubectl run <> --dry-run=client -o yaml >test.yaml にてPodのYAMLファイルを作っている kubectl create role -hでヘルプを表示し、そこからコマンドを作成してRoleを作っていた ダメなところ： 大前提としてケアレスミスをしない、StaticPodは/etc/kubernetes/manifests配下にYAMLを配置する、文字の打ち間違え、デプロイをし忘れをしない 特にPVCの名前間違えだけは気を付ける！PVにも影響するので復旧のタイムロスがでかすぎる！ https://qiita.com/s64s_y/items/b1473695709e39ddba39 メモ： deploymentリソースのロールアウトヒストリーを残すには末尾に --record を付与する kubectl apply -f t04-deploy.yaml --record https://qiita.com/sky0621/items/b935ab6603e9ee9621e0 CSRを作るにはまずはopensslでkeyを作成し、それからcsrを作成する openssl genrsa -out myuser.key 2048 openssl req -new -key myuser.key -out myuser.csr その後CSRリソースを作成するが、事前に作成したcsrに対してcat myuser.csr | base64 | tr -d "\n"を実施する その後、kubectl certificate approve <certificate-signing-request-name>で承認する https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection