【書評】Docker/Kubernetes 実践コンテナ開発入門はまさに「実践」のための本です - まーぽんって誰がつけたの？
今回、レビュアーとして関わらせてもらい、本を頂けたので感想書いていきます。 とにかく内容が充実していて実用的な本です 私自身、業務でもコンテナの運用をやっているのですが各章知らないことがたくさんありました。全部で400ページぐらいあって1人でこの量書くのどれだけ大変だったんだろうという感じです。共著ではないので本全体を通して流れが一貫してると感じました。 まずはDockerの歴史や意義から始まり、Dockerの操作、Dockerfileでイメージの作り方、docker-composeでコンテナ連携と順を追ってステップアップしていきます。 そして、Swarmでオーケストレーション、さらにSwarmで作ったやつをKubernetesでもやってみようの流れから、ローカルでやっていたものをGKEにデプロイして一通りKubernetesのことが体験できるようになってます。さらに、コンテナのロギングな
OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに 本記事は「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の続編となります。保護リソースエンドポイント (protected resource endpoint)、いわゆる世の中でいうところの (狭義の) Web API の実装に関する話題がメインとなります。 1. もう一つの認可 1.1. アカウント属性文脈での認可 混乱を避けるため前記事では敢えて言及しませんでしたが、認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このど
ALBでhttpをhttpsにリダイレクトできるやつが便利だった - まーぽんって誰がつけたの？
今まではnginxでリダイレクトさせてた こんな感じでhttpでアクセスしてきたらhttpsにリダイレクトするっていうのをnginxの設定で書いてました。 if ($http_x_forwarded_proto != https) { return 301 https://$host$request_uri; } これで困るのは ALBからのhealth checkはhttpで来るので、health checkも301が返っちゃうということです。 で、例えばuser agentがELB-healthcheckerで、かつ、httpだったら301じゃなくて200返すとか書けばいいんですが、nginxでand条件のif文書くのは結構大変なのです。（プログラミング言語ではないのでそういうもの） こちらの記事を引用します。こんな感じになっちゃうイメージです。 Nginxで複数条件のIF文を書く方法
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
