Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes APIに Pod内からアクセスしてみた

ry
July 27, 2020

Kubernetes APIに Pod内からアクセスしてみた

ry

July 27, 2020
Tweet

More Decks by ry

Other Decks in Technology

Transcript

  1. 機密 <会社名> 専用 バージョン 1.0
    Kubernetes APIに
    Pod内からアクセスしてみた

    View Slide

  2. 自己紹介
    ry (@URyo_0213)
    インフラエンジニア
    主な仕事内容:
    - Storageの導入・設定 (+ 自動化)
    - 社内app作成
    - 社内app基盤の運用・管理 (kubernetes with PKS)

    View Slide

  3. 機密 <会社名> 専用 バージョン 1.0
    1. 今日学ぶこと
    2. まず初めに
    3. Practice
    4. まとめ
    Agenda

    View Slide

  4. 今日学ぶこと

    View Slide

  5. 今日学ぶこと
    1 RBACについて
    2 Pod内からKubernetes APIを叩く方法

    View Slide

  6. まず初めに

    View Slide

  7. Kubernetes API
    Kubernetesを操作する際の指示を受け取る口。
    CLIツールである「kubectl」や、yaml形式で書かれた「manifest」
    を用いた先では、このAPIを叩いています。

    View Slide

  8. Kubernetes API へのアクセス
    クライアントからのアクセスが入ると、
    ・Authentication(認証)
    アクセスが許可されているかを判断
    ・Authorization(認可)
    処理の権限を持っているのかを判断
    ・Admission Control(リクエスト制御)
    そのリクエストを受け入れるのかを判断
    Authorization
    Authentication
    Client
    Admission Control
    Excecute

    View Slide

  9. PodからAPIを叩くために必要なもの
    1 Service Account
    2 Role / Cluster Role
    3 Role Binding / Cluster Role Binding

    View Slide

  10. Service Account
    01
    kubernetes内で管理され、認証情報をPodに割り当てるリソース
    特徴:
    ・Nampespaceに紐づく。
    ・1つ1つに「Token」と「証明書」が割り当てられる。
    ・Pod起動時にService Accountを必ず1つ割り当てる必要がある。
     (指定しない場合、default service accountが割り当てられる)

    View Slide

  11. Service Account Token

    View Slide

  12. Service Account Token による認証
    1 HTTPリクエスト時、Service Account tokenをHeaderにいれる
    2 Kubernetesは、どのService Accountを使用しているかを認識
    3 認証をpassする

    View Slide

  13. Service Account による認可 (RBAC)
    Role Role Binding Service Account
    Cluster Role Cluster Role Binding Service Account
    どういった操作を許可するのかを定めた Roleを作成し、Service Accountに対して
    RoleBindingを用いてRoleを紐づけることで権限を管理します。

    View Slide

  14. Role / Cluster Role
    02
    付与する権限を指定するリソース
    Role vs Cluster Role
    ここの違いは、Namespaceを跨げるかどうかです。
    Cluster Roleは、Namespaceを跨いでCluster単位でリクエスト権限を与えることができま
    す。

    View Slide

  15. Role / Cluster Role
    設定フィールド
    rulesにリスト形式で指定。
    基本は以下の3つを指定していく。
    ・apiGroups
    リソースが含まれている APIのグループを指定
    ・resources
    このルールを適用するリソースを指定
    ・verbs
    指定したリソースに対して行う操作を指定
    apiGroups
    resources
    create 作成
    get / list 取得 / 一覧取得
    delete 削除
    update 更新
    patch 一部変更
    watch 変更の追跡
    verbs

    View Slide

  16. Role / Cluster Role
    manifest例
    https://kubernetes.io/docs/reference/access-authn-authz/rbac/#command-line-utilities

    View Slide

  17. Role Binding /
    Cluster Role Binding
    03
    RoleとService Account等を紐付けるリソース。
    Role BindingとCluster Role Bindingの違いは、
    Roleと同様、Namespaceを跨げるかどうかです。

    View Slide

  18. Role Binding /
    Cluster Role Binding
    manifest例

    View Slide

  19. Practice

    View Slide

  20. PodからAPIを叩くまでの準備
    1 Service Account作成
    2 Role / Cluster Role作成
    3 Role Binding / Cluster Role Binding作成
    4 Pod作成
    5 Pod Setup

    View Slide

  21. ちょっとその前に!!
    今回のAPI 検証用のNamespaceを作成します。
    # kubectl create ns apitest

    View Slide

  22. Service Account作成
    $ kubectl create sa admin-sa -n apitest
    $ kubectl get sa -n apitest
    NAME SECRETS AGE
    admin-sa 1 9s
    default 1 6m11s

    View Slide

  23. Cluster Role作成
    $ kubectl apply -f cluster-role.yaml -n apitest
    $ kubectl get clusterrole -n apitest \
    |grep admin-role
    admin-role 98s

    View Slide

  24. Cluster Role Binding作成
    $ kubectl apply -f cluster-role.yaml -n apitest
    $ kubectl get clusterrolebinding -n apitest \
    |grep admin-rolebinding
    admin-rolebinding 63s

    View Slide

  25. Pod作成
    $ kubectl apply -f pod.yaml -n apitest
    $ kubectl get pod -n apitest
    NAME READY STATUS RESTARTS AGE
    nginx 1/1 Running 0 2s

    View Slide

  26. Podの中を見てみる
    Podに接続していきます。
    $ kubectl exec -it nginx -- /bin/bash
    [email protected]:/#

    View Slide

  27. 環境変数
    ・API アクセス先
    KUBERNETES_PORT_443_TCP_ADDR
    KUBERNETES_PORT_443_TCP_PORT

    View Slide

  28. Token
    Service AccountのTokenは
    /var/run/secrets/kubernetes.io/serviceaccount/token
    に格納されています。

    View Slide

  29. ca.crt
    APIにアクセスする際に用いる証明書は
    /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    に格納されています。

    View Slide

  30. Set up
    APIにアクセスする際に必要なパラメータを環境変数に仕込んでおきます。

    View Slide

  31. 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

    View Slide

  32. Deploymentの作成
    APIに送るjsonファイルを作成しましょう。
    # vi deployment.json

    View Slide

  33. 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

    View Slide

  34. Deploymentの作成
    適切なRBAC設定を行っていない場合、

    View Slide

  35. 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

    View Slide

  36. Deploymentの確認
    APIからも確認できます。
    # curl -X GET -H "Authorization:Bearer $TOKEN" \
    --cacert $CACERT \
    https://$k8s/apis/apps/v1/namespaces/apitest/deployments/apitest-nginx

    View Slide

  37. Deploymentの確認
    APIでの確認結果
    (長いので、途中まで)

    View Slide

  38. Deploymentの削除
    # curl -X DELETE -H "Authorization:Bearer $TOKEN" \
    --cacert $CACERT \
    https://$k8s/apis/apps/v1/namespaces/apitest/deployments/apitest-nginx
    成功時のstdout

    View Slide

  39. まとめ

    View Slide

  40. まとめ
    1 RBACについては以下の3リソースを用いる。
    Service Account, (Cluster)Role, (Cluster)Role Binding
    2 Pod内からは、指定したService Account の情報を使って
    Kubernetes APIを叩くことができる。

    View Slide

  41. Thank you

    View Slide