「RBAC Lookup」を使って RBAC に関連するオブジェクトを検索する

Kubernetes には RBAC (Role Based Access Control) という仕組みとして，Role / ClusterRole / RoleBinding / ClusterRoleBinding という「計4種類」の Kubernetes オブジェクトがある．Role と ClusterRole ではアクセス権限を宣言して（Namespace を指定するかどうかの違い），RoleBinding と ClusterRoleBinding ではサブジェクト (User / Group / ServiceAccount) との紐付けを宣言する．

kubernetes.io

RBAC Lookup（rbac-lookup コマンド）

RBAC に関連するオブジェクトを確認する場合，普通に kubectl get や kubectl describe を使えば良いけど，RBAC Lookup（rbac-lookup コマンド）を使えば，RBAC に関連するオブジェクトを検索したり，関係をシンプルに表示できる．サッと確認するときに便利！

github.com

RBAC Lookup をインストールする

RBAC Lookup には「2種類」のインストール方法がある．Krew を使う場合は kubectl のサブコマンドとして使えるようになる．Homebrew を使う場合は rbac-lookup コマンドとして使えるようになる．実際に試したところ Krew だと古めの v0.3.0 になってしまうため，今回は Homebrew を使って最新の v0.6.2 にした．Krew の index は以下で確認できるけど，更新されてなさそう...

• krew-index/rbac-lookup.yaml at master · kubernetes-sigs/krew-index · GitHub

1. Krew : kubectl rbac-lookup

$ kubectl krew install rbac-lookup
$ kubectl rbac-lookup version
rbac-lookup version 0.3.0

2. Homebrew : rbac-lookup

$ brew install FairwindsOps/tap/rbac-lookup
$ rbac-lookup version
Version:0.6.2 Commit:030e2484220cd353fa2026b808f5ff0ee1094876

検証環境

今回は Docker Desktop for Mac の Kubernetes 1.19.3 を検証環境として使う．Role / ClusterRole / RoleBinding / ClusterRoleBinding のマニフェストを作った（GitHub に置いてある）．関係性を簡単に図解すると以下のようになる．

• https://github.com/kakakakakku/k8s-manifests/tree/master/sandbox-rbac-lookup

RBAC Lookup を試す

さっそく RBAC Lookup を試す．rbac-lookup コマンドを実行すると，Kubernetes クラスター全体を検索する．今回は rbac-lookup コマンドに検索キーワードを指定して，サブジェクト (User / Group / ServiceAccount) に部分一致検索をすると，以下のように SUBJECT と SCOPE と ROLE が表示される．そして -o wide オプションを追加すると SOURCE も表示される．

• SUBJECT : サブジェクト (User / Group / ServiceAccount)
• SCOPE : Namespace or Kubernetes クラスター (cluster-wide)
• ROLE : Role or ClusterRole
• SOURCE : RoleBinding or ClusterRoleBinding

$ rbac-lookup kakakakakku
SUBJECT                          SCOPE            ROLE
kakakakakku-group                kakakakakku-ns   Role/role-pod-only
kakakakakku-group                cluster-wide     ClusterRole/cluster-role-pod-only
kakakakakku-ns:kakakakakku-sa    kakakakakku-ns   Role/role-pod-only
kakakakakku-ns:kakakakakku-sa    cluster-wide     ClusterRole/cluster-role-pod-only
kakakakakku-user                 kakakakakku-ns   Role/role-pod-only
kakakakakku-user                 cluster-wide     ClusterRole/cluster-role-pod-only

$ rbac-lookup kakakakakku -o wide
SUBJECT                                         SCOPE            ROLE                                SOURCE
Group/kakakakakku-group                         kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
Group/kakakakakku-group                         cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only
ServiceAccount/kakakakakku-ns:kakakakakku-sa    kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
ServiceAccount/kakakakakku-ns:kakakakakku-sa    cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only
User/kakakakakku-user                           kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
User/kakakakakku-user                           cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only

同じように検索キーワード system:master に関連するオブジェクトを検索することもできる．RBAC に関連するオブジェクトを個別に調べる必要はなく，便利だと思う．

$ rbac-lookup system:master
SUBJECT           SCOPE          ROLE
system:masters    cluster-wide   ClusterRole/cluster-admin

$ rbac-lookup system:master -o wide
SUBJECT                 SCOPE          ROLE                        SOURCE
Group/system:masters    cluster-wide   ClusterRole/cluster-admin   ClusterRoleBinding/cluster-admin

--kind オプションを使う

--kind オプションを使うと，サブジェクト (User / Group / ServiceAccount) を指定して絞り込むことができる．

$ rbac-lookup kakakakakku -o wide --kind user
SUBJECT                  SCOPE            ROLE                                SOURCE
User/kakakakakku-user    kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
User/kakakakakku-user    cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only

$ rbac-lookup kakakakakku -o wide --kind group
SUBJECT                    SCOPE            ROLE                                SOURCE
Group/kakakakakku-group    kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
Group/kakakakakku-group    cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only

$ rbac-lookup kakakakakku -o wide --kind serviceaccount
SUBJECT                                         SCOPE            ROLE                                SOURCE
ServiceAccount/kakakakakku-ns:kakakakakku-sa    kakakakakku-ns   Role/role-pod-only                  RoleBinding/role-binding-pod-only
ServiceAccount/kakakakakku-ns:kakakakakku-sa    cluster-wide     ClusterRole/cluster-role-pod-only   ClusterRoleBinding/culster-role-binding-pod-only

まとめ

RBAC に関連するオブジェクトを検索したり，関係をシンプルに表示できる RBAC Lookup（rbac-lookup コマンド） を試した．サッと確認するときに便利！kubectl コマンドを実行する環境にインストールしておこう！

github.com

kubecolor を使って kubectl の実行結果を色付けしよう

kubecolor コマンドを使うと kubectl コマンドの実行結果を色付けして読みやすくできる．kubectl コマンドの実行結果は基本的に白黒なので，リソース数が多かったり，例えば -o wide オプションを使って表示項目を増やしたりすると，読みにくくなることもある．

また技術講師として研修で Kubernetes を教える機会も多く，kubectl コマンドの実行結果を説明するときに「青の〜」や「黄色の〜」という表現が使えると，特にリモート研修で注目して欲しい部分を正確に伝えられる．今回は kubecolor コマンドを紹介する．

github.com

kubecolor をインストールする

Linux と Mac なら kubecolor コマンドは brew コマンドで簡単にインストールできる．また go get コマンドで直接インストールすることもできるし，GitHub Releases からバイナリをダウンロードして使うこともできる．brew コマンドを使った場合は現時点だと v0.0.8 になる．数日前に最新版 v0.0.9 もリリースされている．詳しくは GitHub リポジトリ参照！

$ brew install dty1er/tap/kubecolor

また kubecolor コマンドは内部的に kubectl コマンドを実行するため，基本的には kubectl コマンドを置き換えて問題ないと思う．GitHub リポジトリの README.md にもそう書いてある．よって，慣れた k コマンドを kubecolor コマンドのエイリアスに設定しても良いし，タブ補完 (complete) も問題なく使える．例えば Mac だと .zshrc に以下のように設定している．

source <(kubectl completion zsh)
alias k='kubecolor'
complete -o default -F __start_kubectl kubecolor k

kubecolor を使う

サンプルとして，Deployment 経由で Pod を3個起動しておく．そして kubecolor get pods コマンドと kubecolor get pods -o wide コマンドを実行した結果を以下に載せる．従来の白黒と比較して，とても読みやすくなっていると思う．

kubecolor コマンドは get や describe など READ 関連コマンドをサポートしているため，次は kubecolor describe pods xxx コマンドを実行した結果を以下に載せる．特に describe は表示項目が多いため，少しでも色付けできると読みやすくなる．

kubecolor コマンドは YAML フォーマットもサポートしているため，最後は kubecolor get pods xxx -o yaml コマンドを実行した結果を以下に載せる．複雑な YAML フォーマットも少しは読みやすくなっていると思う．

なお，そもそも YAML フォーマットの「冗長な」情報を削除して読みやすくするなら，別記事で紹介した kubectl-neat も併用できる．kubecolor neat get pods xxx -o yaml のように kubectl-neat を「ラッパー」で実行すれば，うまく色付けできる．

kakakakakku.hatenablog.com

kubecolor で使えるオプション

kubecolor コマンドで --light-background オプションを使えば，白背景などにも対応できる．実際に iTerm2 で試したところ，逆に読みにくくなることもあった．カラースキーマとの相性もあるため組み合わせを模索すると良さそう．また --plain オプションを使えば，kubecolor コマンドを使いつつ色付けを無効化できる．

iterm2colorschemes.com

まとめ

kubecolor コマンドを使うと kubectl コマンドの実行結果に色付けをして読みやすくできる．慣れた k コマンドのエイリアスに設定できるし，タブ補完 (complete) も使える．基本的には kubectl コマンドに影響は及ぼさないため，興味があったら試してみると良いかと！

github.com

kubectl-neat を使って Kubernetes のマニフェストをスッキリ表示する

「kubectl-neat（kubectl neat コマンド）」を使うと Kubernetes のマニフェストから「冗長な」情報を削除して表示できる．知っておくと便利！GitHub リポジトリの README.md を読むと「メタデータ」や「デフォルト設定」や「Admission Controllers によって作られた情報」によって読みにくくなると書いてある．さっそく「kubectl-neat」を紹介していく．

github.com

検証環境

• Docker Desktop for Mac
• Kubernetes 1.19.3

事前確認 : kubectl get pods xxx -o yaml コマンド

「kubectl-neat」を試す前に事前確認として kubectl get pods xxx -o yaml コマンドを確認する．kubectl get pods コマンドに -o yaml オプションを追加すると，Pod の状態を YAML 形式で詳細に確認できる．まず，以下のマニフェストを作る．

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-kubectl-neat-pod
  labels:
    app: sandbox-kubectl-neat
spec:
  containers:
    - name: nginx
      image: nginx:1.19-alpine
      ports:
        - containerPort: 80

マニフェストを適用して kubectl get pods xxx -o yaml コマンドを実行すると，以下のように表示される．metadata.* も spec.* も status.* も非常に多くの情報が含まれている．全部載せると長すぎるため今回は割愛して載せる．ザッとスクロールをしてもらって OK！

$ kubectl get pods sandbox-kubectl-neat-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    （中略）
  creationTimestamp: "2021-01-01T13:00:00Z"
  labels:
    app: sandbox-kubectl-neat
  managedFields:
    （中略）
  name: sandbox-kubectl-neat-pod
  namespace: default
  （中略）
spec:
  containers:
  - image: nginx:1.19-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-klk8p
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: docker-desktop
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-klk8p
    secret:
      defaultMode: 420
      secretName: default-token-klk8p
status:
  （中略）

「kubectl-neat」をインストールする

「kubectl-neat」は kubectl プラグインとして提供されているため，Krew を使えば簡単にインストールできる．kubectl krew install neat コマンドでインストールすれば，kubectl neat help コマンドが実行できるようになる．

$ kubectl krew install neat

Installing plugin: neat
Installed plugin: neat
\
 | Use this plugin:
 |  kubectl neat
 | Documentation:
 |  https://github.com/itaysk/kubectl-neat
/

$ kubectl neat help

なお，最初に Krew をインストールしておく必要があるため，はじめて使う場合は以下のドキュメントを参照する．

krew.sigs.k8s.io

「kubectl-neat」を試す

さっきと同じ Pod に対して「kubectl-neat」を試す．実行する方法は大きく2種類あり「kubectl get pods xxx -o yaml | kubectl neat のようにパイプをする方法」と「kubectl neat get pods xxx -o yaml のようにラッパーとして使う方法」がある．

実際に「kubectl-neat」を使うと，以下のように表示される．非常にスッキリした！個人的に使うのに便利だし，デモをするときに「意図的に」情報量を落とす場合などに使えそう．実際にデモをする場合は「kubectl-neat」を使う意図を明確に伝えておく必要がありそう．

$ kubectl get pods sandbox-kubectl-neat-pod -o yaml | kubectl neat
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: sandbox-kubectl-neat
  name: sandbox-kubectl-neat-pod
  namespace: default
spec:
  containers:
  - image: nginx:1.19-alpine
    name: nginx
    ports:
    - containerPort: 80
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  serviceAccountName: default
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300

マニフェストに ServiceAccount を指定する

GitHub リポジトリの README.md を読むと「kubectl-neat」によって削除される条件（Admission Controllers 対応表）が載っている．例えば ServiceAccount だと，以下のように default-token-* に該当するボリュームは削除されると書いてある．

Remove default-token-* volumes. Remove deprecated spec.serviceAccount

さっきと同じ Pod のマニフェストに serviceAccountName を指定して，適用しておく．

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-kubectl-neat-pod
  labels:
    app: sandbox-kubectl-neat
spec:
  serviceAccountName: sandbox-kubectl-neat-service-account
  containers:
    - name: nginx
      image: nginx:1.19-alpine
      ports:
        - containerPort: 80

もう1度 kubectl get pods sandbox-kubectl-neat-pod -o yaml | kubectl neat を実行して事前確認との差分を以下に載せる．今度はボリューム関連のマニフェストが追加されていた．これは「kubectl-neat」の仕様通り，default-token-* に該当せずに表示されている．

@@ -12,9 +12,13 @@
     name: nginx
     ports:
     - containerPort: 80
+    volumeMounts:
+    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+      name: sandbox-kubectl-neat-service-account-token-n59lc
+      readOnly: true
   preemptionPolicy: PreemptLowerPriority
   priority: 0
-  serviceAccountName: default
+  serviceAccountName: sandbox-kubectl-neat-service-account
   tolerations:
   - effect: NoExecute
     key: node.kubernetes.io/not-ready
@@ -24,3 +28,7 @@
     key: node.kubernetes.io/unreachable
     operator: Exists
     tolerationSeconds: 300
+  volumes:
+  - name: sandbox-kubectl-neat-service-account-token-n59lc
+    secret:
+      secretName: sandbox-kubectl-neat-service-account-token-n59lc

まとめ

「kubectl-neat（kubectl neat コマンド）」を使うと Kubernetes のマニフェストから「冗長な」情報を削除して表示できる．知っておくと便利！デモをするときに「意図的に」情報量を落とす場合などに使えそう．

github.com

「あのサービスに似たサービス」を探せる AlternativeTo

「AlternativeTo」を使うと「あのサービス（ツール）に似たサービス（ツール）」を探せる．有名な Product Hunt にも Alternative products という機能があって似ているけど，「AlternativeTo」はサービスだけではなくツールも多く登録されている．個人的によく使っていることもあり，今回は「AlternativeTo」を紹介する．

• AlternativeTo - Crowdsourced software recommendations

Visual Studio Code (VS Code)

「AlternativeTo」で Visual Studio Code (VS Code) を調べると，Atom や IntelliJ IDEA など，他のエディタを探せる．他には Brackets など，今まで使ったことがなかった（もはや存在すら知らなかった）エディタに出会うこともできる．

• Visual Studio Code Alternatives: 25+ Code and Text Editors | AlternativeTo

Postman

次に API Client としてよく使われている Postman を調べると，Insomnia REST Client や Paw など，人気のある API Client を探せる．さらに Advanced REST client など，Chrome 拡張機能まで探せるのは「AlternativeTo」の良いところだと思う．

• Best Postman Alternatives: 25+ API / REST Development tools | AlternativeTo

Trello

今度はタスク管理ツールとしてよく使われている Trello を調べると，Wrike や Taiga.io や Asana など，たくさんのタスク管理ツールに出会える．その中でも ClickUp は機能も多く，興味を持ったので，無料アカウントを作って試しているところ．

• Trello Alternatives: Replace Trello with any of these 25+ alternatives | AlternativeTo

IFTTT

サービスを組み合わせて自由にワークフローを構築できる IFTTT を調べると，Zapier はとても人気がありそうだった．

IFTTT Alternatives: 25+ Task and Workflow Automation Tools | AlternativeTo

他には n8n.io も載っている．実は今月に n8n.io に入門した記事を書いたのは「AlternativeTo」で発見したことに繋がっている．「AlternativeTo」を使って「ブログネタ」を探すことにも活用できる！便利！

kakakakakku.hatenablog.com

まとめ

「AlternativeTo」を使うと「あのサービス（ツール）に似たサービス（ツール）」を探せる．例えば，新しくツールを導入するときに「代替案はある？」と聞かれても困らないように事前に調べたり，使っているサービスに似たサービスを探してブログネタにしたり，いろいろと活用できる．ブックマークしておくと便利なサイトだと思う！

3年間続けた「ブログメンタリング」の振り返りと2021年の方向性

2017年12月から「ブログメンタリング」という個人活動を続けて「3年間」になった．ブログメンタリングを簡単に表現すると「技術ブログに悩んでいる人の悩みを解消する 1 on 1」と言える．ブログメンタリング内容などの詳細は，2019年6月に DevLOVE X で登壇した資料を見てもらえると今でも参考になるはず！今回の記事では，3年間のブログメンタリングを振り返りつつ，2021年の方向性をまとめる．

Stats 📝

3年間でブログメンタリング卒業生は「計58名」になった．ブログメンタリングでは最大3ヶ月として自由に卒業期間を選べる（月末に決めてもらう）仕組みにしてある．メンタリング期間の割合としては以下のようになる．55% (32名) は「3ヶ月」を選ばれた．ブログメンタリング自体に期待していたことと大きく違っていたり，急遽続けられなくなってしまった場合のみ，1ヶ月もしくは2ヶ月目途中での卒業もあった．

メリット 📝

「ブログメンタリング」という名前だけ聞くと，とても怪しく（胡散臭く）感じるだろうし，アフィリエイト生活を目指しそうな雰囲気もあるけど（笑）意図的にそういうネーミングにした．実際には「テックブログ習慣化」や「記事クオリティ向上」や「ソーシャル活用術」など，テックブログを軸に幅広く「アウトプット」を実践していく．

普段ブログ記事をレビューしてもらうという機会は少なく貴重だと思うし，ブログメンタリング開始前にヒアリングした個別の課題感にフォーカスした「最善のアドバイス」を「最善なタイミング」で提供するコミュニケーションにも価値があると思う．ブログメンタリングを「自己ブランディング向上」に活用したメンティもいれば，三日坊主にならないための「矯正ギブス」としての役割を希望されていたメンティもいた．またブログメンタリング卒業生ならわかる「卒業フィードバック」も長文でよく驚かれる．詳しくは卒業ブログを検索してみてもらえればと！

課題 1 : スケーラビリティ 📝

僕自身「メンタリング」は本気で取り組んでいるし，日々多くの時間を投資しているけど，あくまで個人活動（趣味）ではあるため，同時に受けられるメンティ数には限界がある．過去最大で「同時に9名」を受けたこともあったけど，仕事とのバランスも考慮すると「同時に4名前後」がベストだった．そして，Stats にも載せた通り，多くのメンティがメンタリング期間として「2-3ヶ月」を希望されるため，新規メンティ募集のタイミングは「1年に3,4回」となる．特に2019年からは募集人数を超える応募があり，倍率が高くなってお断りをする場面も多々あり，結果的に僕自身の「スケーラビリティ」に課題を感じていた．

課題 2 : 一時的なブースト役 📝

ブログメンタリングを卒業したら，当然ながらノルマ生活をする必要はなく，ある意味「縛り」からは解放される．またブログメンタリング卒業後に「あえて」ブログを書かないことを選んだり，更新頻度を下げたりするメンティもいる．ブログメンタリングに参加して「自信を持って継続的に書かないことに決められた」というフィードバックもあり，素晴らしいと思う．多種多様な結果があって興味深い！

課題としては，卒業後に「時間捻出」や「ネタ切れ」や「モチベーション低下」などの理由でブログの更新が止まってしまったメンティが実際にいたりして，これはブログメンタリングを通して「伝えるべきことを伝えられていなかった」という観点においては僕自身にも責任があると考えている．言い換えると，ブログメンタリングの役割が「健康ドリンク」のように「一時的なブースト役」になってしまっていた可能性がある．例えば，ライザップで食生活などを改善して痩せたとしても，すぐにリバウンドをしてしまうのと似ているように感じる．ようするに「中長期的な習慣化」に実はアプローチできていなかったのでは？という点も課題だった．

ブログメンタリング 2021 : テックブログ Tips マガジン (仮) 📝

「4年目」となるブログメンタリングでは，今までと違うスタイルに挑戦してみることにした．「テックブログ Tips マガジン」というのはあくまで仮名だし正式名称は付けないかもしれないけど，2021年は「3年間のブログメンタリングで伝えていたテックブログ Tips を整理してブログで定期的に紹介する」という企画に挑戦する．特に上記の課題2点を解決するアプローチにすることを強く意識している．逆に今までの良さでもあった「1 on 1（パーソナルメンタリング）」というメリットはなくなる．トレードオフだと思う．あくまで検証も兼ねた企画になるため，様子を見ながらやっていく．お楽しみに！

4年目も引き続き趣味として 📝

ブログメンタリング卒業生から「これで無料なのは意味不明すぎる」と褒めていただくことも多いけど，僕としてはあくまで個人活動（趣味）の範囲でやらせてもらっている．だからこそ「Amazon のほしい物リストでお返しさせてもらえませんか？」と言っていただけてもお断りしているし（ありがとうございます！），他にも「有償でテックブログを監修してもらえませんか？」という相談や「メンタープラットフォームに登録しませんか？」という紹介もいただくけど，現時点では全て断っている．まだまだ趣味として試行錯誤のフェーズだし，マネタイズできるようなクオリティではないと思う．4年目もスタイルは違えど引き続き趣味として頑張っていく！

まとめ 📝

3年間続けてきた「ブログメンタリング」を振り返りつつ，2021年の方向性をまとめた．お楽しみに！

関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com