FIDO2 をアプリケーションに組み込むときのちょっとした Tips や考慮しないといけないことを思いつくままにまとめてみようと思います。思いつく＆何か新しい発見があるたびに記事は随時更新していきます。
まずは、Chrome の拡張機能の紹介です。組織のポリシーなどで会社支給のパソコンからinternalの認証器が呼び出せないパターンもあるでしょう。例えば、デモやちょっとした検証をやりたいのにわざわざそのために USB セキュリティキーを買うのもちょっと馬鹿らしいですよね。そんな時に非常に役に立ちます。
使い方自体は非常に簡単で、まずは chrome ウェブストア - Virtual Authenticators Tabで当該機能を有効化する。
Virtual Authenticators Tab を追加しますか？ というポップアップが出てくるので、拡張機能を追加 を押して追加する。
確認には、おなじみのwebauthn.ioが良いと思います。
まずは、DevTool を開き追加されているVirtual Authenticators内にあるEnable Virtual Authenticator Environmentのチェックボックスにチェックを入れます。
後は、お好きな仮想認証器を生成してください。一応、設定できるパラメータを解説すると
internalが選択できそうですが、作成の際にエラーメッセージが出力されます※2021/05/28 追記
Auth0 が作成しているデモサイトがかなり良かったのでその紹介です。(https://webauthn.me/)
FIDO2 の一連のフローが視覚的に分かりやすく整理されています。下手なデモを作成するよりはフローを紹介した後、このサイトに誘導する方が理解度は高まるかもしれない。
題名の通りです。Google Analytics のトラッキング ID を設定する箇所があることも最近知ったのですが、 API が特に手続きなしで使えることも知りませんでした...
Google Analytics でカバーできない記事の view 数を（KPI などで）今後もしかしたら使うかもしれないので、いざという時のためにスクリプトを書いてみました。
#!/bin/bash
ACCESS_TOKEN=<your-access-token>
ITEM_IDs=`curl https://qiita.com/api/v2/authenticated_user/items \
--header "Authorization: Bearer ${ACCESS_TOKEN}" \
| jq -r '.[] | [.id] | @csv'`
for ITEM_ID in $ITEM_IDs
do
ITEM_ID=`echo $ITEM_ID | tr -d '"'`
ITEM=`curl -s https://qiita.com/api/v2/items/${ITEM_ID} \
--header "Authorization: Bearer ${ACCESS_TOKEN}"`
TITLE=`echo $ITEM | jq -r '.title'`
VIEW=`echo $ITEM | jq -r '.page_views_count'`
echo $TITLE: $VIEW
done
実行すると、こんな感じで取得できます。（未公開の記事も含まれていそう）
OCI DevOps で Oracle Functions の CI/CD - パイプライン作成編: 366 OCI DevOps で Oracle Functions の CI/CD - 事前準備編: 470 Helidon 2.4.0 で導入された OpenID Connect のログアウト機能(RP-Initiated Logout)について: 519 OCI API Gateway のレスポンスキャッシュ機能について: 654 MAN スタックで WebAuthn - ユーザー登録編: 10 OKEでARMコンテナを動かす: 858 OCI API Gateway の認証・認可機能について: 1283 Java Management Service ことはじめ: 937 Helidon + IDCSでFIDO認証: 1158 Helidon MP, WebAuthn4Jで簡易的なRelying Partyを実装してみる: 1214 OCI StreamingをSDK経由で触ってみた: 747 JWT Validatorことはじめ: 929 Spring Boot, Doma2, Gradleの初期設定まとめ: 5405 今更ながらSpring Data JPAを触ってみる: 13172 MANスタックでWebAuthn - ユーザー認証編: 1313 MANスタックでWebAuthn - ユーザ登録編: 2286 職務経歴書をGitLab Pages を使って公開してみた: 2792 Angular9でBootstrap4を使う: 5399 Nest.jsのDB接続周りでハマった話: 7744 WSL2でWindows10の開発環境を整える: 8762
題名そのまんまです。Secret に設定されているのでそれを参照します。私は、Prometheus Operator を使って環境を作成しましたが、他でも手順は同じです。 まずは、Secret の確認。
kubectl -n monitoring get secrets
NAME TYPE DATA AGE default-token-khm2r kubernetes.io/service-account-token 3 31d jaeger-operator-token-xhppz kubernetes.io/service-account-token 3 31d prometheus-grafana Opaque 3 31d prometheus-grafana-test-token-ngb6k kubernetes.io/service-account-token 3 31d prometheus-grafana-token-l5b79 kubernetes.io/service-account-token 3 31d prometheus-kube-state-metrics-token-52h22 kubernetes.io/service-account-token 3 31d prometheus-operator-token-fns8q kubernetes.io/service-account-token 3 31d prometheus-prometheus-node-exporter-token-hzdsm kubernetes.io/service-account-token 3 31d prometheus-prometheus-oper-admission Opaque 3 31d prometheus-prometheus-oper-operator-token-dl4hg kubernetes.io/service-account-token 3 31d prometheus-prometheus-oper-prometheus-token-wh28n kubernetes.io/service-account-token 3 31d prometheus-prometheus-prometheus-oper-prometheus Opaque 1 31d prometheus-prometheus-prometheus-oper-prometheus-tls-assets Opaque 0 31d sh.helm.release.v1.prometheus.v1 helm.sh/release.v1 1 31d
これの prometheus-grafana ってやつに含まれています。
kubectl -n monitoring get secrets prometheus-grafana -o json
{
"apiVersion": "v1",
"data": {
"admin-password": "cHJvbS1vcGVyYXRvcg==",
"admin-user": "YWRtaW4=",
"ldap-toml": ""
},
"kind": "Secret",
"metadata": {
"annotations": {
"meta.helm.sh/release-name": "prometheus",
"meta.helm.sh/release-namespace": "monitoring"
},
"creationTimestamp": "2021-12-20T12:35:25Z",
"labels": {
"app.kubernetes.io/instance": "prometheus",
"app.kubernetes.io/managed-by": "Helm",
"app.kubernetes.io/name": "grafana",
"app.kubernetes.io/version": "6.7.3",
"helm.sh/chart": "grafana-5.0.18"
},
"name": "prometheus-grafana",
"namespace": "monitoring",
"resourceVersion": "284323",
"uid": "9856672f-b874-4640-9d1c-b84113bd7044"
},
"type": "Opaque"
なので、これでOK。
kubectl -n monitoring get secrets prometheus-grafana -o jsonpath='{.data.admin-password}' | base64 -d
2021 年の年末から Kubernetes 認定資格（CKA）のお勉強を本格的に開始しました。この記事は、資格対策講座で勉強しながら”これ試験でも使いそう...!!”と思ったものを自分のためにメモしていくものです。（※随時追記します）
試験が始まったら、まずこれ。他にもありそうだけど、個人的には一旦これで十分な気がしている。
bash シェルにコマンド補完を設定する。
source <(kubectl completion bash) echo "source <(kubectl completion bash)" >> ~/.bashrc
エイリアスを設定する。
alias k=kubectl complete -F __start_kubectl k
ちなみに、Kubernetes の公式ドキュメントのチートシートに記載があるので、試験本番中も閲覧可能。
--dry-run=client -o yaml は、めちゃ使うので、環境変数とかで設定しておくと良さそう。
export do="--dry-run=client -o yaml" # この辺はお好みで... export oj="-o json" export oy="-o yaml" export ow="-o wide"
ついでに、.vimrc に以下の設定をしておく。
set tabstop=2 set expandtab set shiftwidth=2 set autoindent set number set ignorecase
とにかく時間が足りないらしいので、極力 Manifest を手書きで書くことは避ける。
そのまま、作成する場合
k run <pod-name> --image=<image-name>
一旦、YAML 形式で出力してから手直しする場合（securityContext や toleration など kubectl のオプションに含まれていない設定を行う場合）
k run <pod-name> --image=<image-name> --dry-run=client -o yaml > <file-name>
ここで指しているリソースは以下の通り。特に、clusterrole, clusterrolebinding, deployment, namespace, role, rolebinding, secret, service, serviceaccount 辺りはよく使うのでヘルプしなくてもある程度は使えるようになっておいた方がいい。
そのまま作成する場合
k create <resource-name> ...
一旦、YAML 形式で出力してから手直しする場合
k create <resource-name> --dry-run=client -o yaml > <file-name>
-o wide で OK
k get po -o wide
Network Policy の設定等の際に、ラベル付きで一覧表示したいときに使う。
--show-labels でOK
k get po --show-labels
ドキュメントに記載の Manifest を参照するか、 一部分だけ分からないなら explain で調べる。
k explain po.spec
CKA では試験中にドキュメントを参照できます。一応サイト内に検索機能はあるのですが、本番中に許可されていないサイトへのリンクも含まれているためちょっとリスキーです。そのため、基本は自分のブックマークから飛ぶと良いでしょう。（と言いつつ、私は普通にサイト内検索しまくりましたが...）一応、当日はこんな感じのブックマークを作成していました。ほとんど使わなかったけど... ご参考までに。