Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes APIに Pod内からアクセスしてみた
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ry
July 27, 2020
Technology
2k
1
Share
Kubernetes APIに Pod内からアクセスしてみた
ry
July 27, 2020
More Decks by ry
See All by ry
Kubernetesにおける推論基盤
ry
3
740
eBPF Tools on Kubernetes part1
ry
0
350
Vault Secrets Operator Tutorial
ry
0
600
KyvernoとRed Hat ACMを用いたマルチクラスターの一元的なポリシー制御
ry
0
1.3k
明日から始められるKyvernoを用いたポリシー制御
ry
4
930
CNDT2022 k8snovice Community introduction
ry
0
180
Policy Engine on Kubernetes
ry
1
1.5k
ConfigMap and Secret
ry
0
410
Policy Manager試してみた!
ry
0
460
Other Decks in Technology
See All in Technology
プラットフォームエンジニアリングの実践 - AWS コンテナサービスで構築する社内プラットフォーム / AWS Containers Platform Meetup #1
literalice
1
230
Claude Code を安全に使おう勉強会 / Claude Code Security Basics
masahirokawahara
12
39k
VespaのParent Childを用いたフィードパフォーマンスの改善
taking
0
180
GitHub Copilot CLI と VS Code Agent Mode の使い分け
tomokusaba
0
130
MySQL 9.7がやってきた ~これまでのあらすじと基本情報~ @ 日本MySQLユーザ会会2026年04月 / mysql97-yattekita
sakaik
0
160
自動テストだけで リリース判断できるチームへ - 鍵はテストの量ではなくリリース判断基準の再設計にあった / Redesigning Release Criteria for Lightweight Releases
ewa
5
3k
巨大プラットフォームを進化させる「第3のROI」
recruitengineers
PRO
2
2.2k
AI駆動開発で生産性を追いかけたら、行き着いたのは品質とシフトレフトだった
littlehands
0
250
ハーネスエンジニアリングをやりすぎた話 ~そのハーネスは解体された~
gotalab555
5
2k
EMから幅を広げるために最近挑戦していること / Recent challenges I'm undertaking to expand my horizons beyond EM
hiro_torii
1
180
もっとコンテンツをよく構造化して理解したいので、LLM 時代こそ Taxonomy の設計品質に目を向けたい〜!
morinota
0
130
AI活用時代の事業判断高度化を導くエンジニアリング基盤 / 20260424 Atsushi Funahashi
shift_evolve
PRO
2
120
Featured
See All Featured
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.6k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
200
Mobile First: as difficult as doing things right
swwweet
225
10k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.7k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
190
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.2k
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
690
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
430
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
170
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
180
Reality Check: Gamification 10 Years Later
codingconduct
0
2.1k
The browser strikes back
jonoalderson
0
1k
Transcript
機密 <会社名> 専用 バージョン 1.0 Kubernetes APIに Pod内からアクセスしてみた
自己紹介 ry (@URyo_0213) インフラエンジニア 主な仕事内容: - Storageの導入・設定 (+ 自動化) -
社内app作成 - 社内app基盤の運用・管理 (kubernetes with PKS)
機密 <会社名> 専用 バージョン 1.0 1. 今日学ぶこと 2. まず初めに 3.
Practice 4. まとめ Agenda
今日学ぶこと
今日学ぶこと 1 RBACについて 2 Pod内からKubernetes APIを叩く方法
まず初めに
Kubernetes API Kubernetesを操作する際の指示を受け取る口。 CLIツールである「kubectl」や、yaml形式で書かれた「manifest」 を用いた先では、このAPIを叩いています。
Kubernetes API へのアクセス クライアントからのアクセスが入ると、 ・Authentication(認証) アクセスが許可されているかを判断 ・Authorization(認可) 処理の権限を持っているのかを判断 ・Admission Control(リクエスト制御)
そのリクエストを受け入れるのかを判断 Authorization Authentication Client Admission Control Excecute
PodからAPIを叩くために必要なもの 1 Service Account 2 Role / Cluster Role 3
Role Binding / Cluster Role Binding
Service Account 01 kubernetes内で管理され、認証情報をPodに割り当てるリソース 特徴: ・Nampespaceに紐づく。 ・1つ1つに「Token」と「証明書」が割り当てられる。 ・Pod起動時にService Accountを必ず1つ割り当てる必要がある。 (指定しない場合、default
service accountが割り当てられる)
Service Account Token
Service Account Token による認証 1 HTTPリクエスト時、Service Account tokenをHeaderにいれる 2 Kubernetesは、どのService
Accountを使用しているかを認識 3 認証をpassする
Service Account による認可 (RBAC) Role Role Binding Service Account Cluster
Role Cluster Role Binding Service Account どういった操作を許可するのかを定めた Roleを作成し、Service Accountに対して RoleBindingを用いてRoleを紐づけることで権限を管理します。
Role / Cluster Role 02 付与する権限を指定するリソース Role vs Cluster Role
ここの違いは、Namespaceを跨げるかどうかです。 Cluster Roleは、Namespaceを跨いでCluster単位でリクエスト権限を与えることができま す。
Role / Cluster Role 設定フィールド rulesにリスト形式で指定。 基本は以下の3つを指定していく。 ・apiGroups リソースが含まれている APIのグループを指定
・resources このルールを適用するリソースを指定 ・verbs 指定したリソースに対して行う操作を指定 apiGroups resources create 作成 get / list 取得 / 一覧取得 delete 削除 update 更新 patch 一部変更 watch 変更の追跡 verbs
Role / Cluster Role manifest例 https://kubernetes.io/docs/reference/access-authn-authz/rbac/#command-line-utilities
Role Binding / Cluster Role Binding 03 RoleとService Account等を紐付けるリソース。 Role
BindingとCluster Role Bindingの違いは、 Roleと同様、Namespaceを跨げるかどうかです。
Role Binding / Cluster Role Binding manifest例
Practice
PodからAPIを叩くまでの準備 1 Service Account作成 2 Role / Cluster Role作成 3
Role Binding / Cluster Role Binding作成 4 Pod作成 5 Pod Setup
ちょっとその前に!! 今回のAPI 検証用のNamespaceを作成します。 # kubectl create ns apitest
Service Account作成 $ kubectl create sa admin-sa -n apitest $
kubectl get sa -n apitest NAME SECRETS AGE admin-sa 1 9s default 1 6m11s
Cluster Role作成 $ kubectl apply -f cluster-role.yaml -n apitest $
kubectl get clusterrole -n apitest \ |grep admin-role admin-role 98s
Cluster Role Binding作成 $ kubectl apply -f cluster-role.yaml -n apitest
$ kubectl get clusterrolebinding -n apitest \ |grep admin-rolebinding admin-rolebinding 63s
Pod作成 $ kubectl apply -f pod.yaml -n apitest $ kubectl
get pod -n apitest NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 2s
Podの中を見てみる Podに接続していきます。 $ kubectl exec -it nginx -- /bin/bash root@nginx:/#
環境変数 ・API アクセス先 KUBERNETES_PORT_443_TCP_ADDR KUBERNETES_PORT_443_TCP_PORT
Token Service AccountのTokenは /var/run/secrets/kubernetes.io/serviceaccount/token に格納されています。
ca.crt APIにアクセスする際に用いる証明書は /var/run/secrets/kubernetes.io/serviceaccount/ca.crt に格納されています。
Set up APIにアクセスする際に必要なパラメータを環境変数に仕込んでおきます。
Set up 必要なmoduleをダウンロードしておきます。 # apt update # apt install -y
curl # apt install -y vim APIへアクセスできるか確認してみましょう。 # curl -H "Authorization: Bearer $TOKEN" --cacert $CACERT https://$k8s/healthz ok
Deploymentの作成 APIに送るjsonファイルを作成しましょう。 # vi deployment.json
Deploymentの作成 APIにjsonファイルを送ります。 # curl -X POST -H "Authorization:Bearer $TOKEN" \
--cacert $CACERT -H 'Content-Type:application/json' \ -d @deployment.json https://$k8s/apis/apps/v1/namespaces/apitest/deployments apiGroup Namespace resoure
Deploymentの作成 適切なRBAC設定を行っていない場合、
Deploymentの確認 別terminalから確認します。 $ kubectl get pods -n apitest NAME READY
STATUS RESTARTS AGE apitest-nginx-78478c4bdc-27v7p 1/1 Running 0 50s apitest-nginx-78478c4bdc-v4fsl 1/1 Running 0 50s apitest-nginx-78478c4bdc-wjzn9 1/1 Running 0 50s nginx 1/1 Running 0 55m
Deploymentの確認 APIからも確認できます。 # curl -X GET -H "Authorization:Bearer $TOKEN" \
--cacert $CACERT \ https://$k8s/apis/apps/v1/namespaces/apitest/deployments/apitest-nginx
Deploymentの確認 APIでの確認結果 (長いので、途中まで)
Deploymentの削除 # curl -X DELETE -H "Authorization:Bearer $TOKEN" \ --cacert
$CACERT \ https://$k8s/apis/apps/v1/namespaces/apitest/deployments/apitest-nginx 成功時のstdout
まとめ
まとめ 1 RBACについては以下の3リソースを用いる。 Service Account, (Cluster)Role, (Cluster)Role Binding 2 Pod内からは、指定したService
Account の情報を使って Kubernetes APIを叩くことができる。
Thank you