連載5回目となる今回は、Istioを用いたマイクロサービスのシステムをKeycloakを用いて認証強化する手順を紹介します。 第五回からは、内部向けのAPIであるマイクロサービスの認証を強化する最先端の機能をご紹介します。第四回までは、APIセキュリティを考えるうえで最も重要である、外部ネットワークと内部ネットワークの境界部分に着目してハードニング方法を説明してきました(図1)。
Goアプリケーション*4など、静的リンクしているバイナリでは利用できないsuidしたバイナリはTelepresence Shell内で動作しない/etc/resolv.confをパースするようなカスタムDNSリゾルバ、自身に対するDNS lookupは動かない *2:全制約事項についてはa href="https://www.telepresence.io/reference/methods" target="blank">公式ページを参照してください。 *3:LinuxのLD_PRELOADとmacOSのDYLD_INSERT_LIBRARIESを利用した方法で、詳細はこちらのブログで詳しく解説されています。 *4:go buildではなくgccgoによるビルドやGODEBUG環境変数でnetdnsのリゾルバをcgoに変更するなどのワークアラウンドは存在しますが、非推奨です。 *5:--
連載の1回目である今回は、Keyclooakの基本および、API保護が必要とされる背景について解説します。 サービスがより活発に利用されることを狙って、企業や公的機関によるサービスのAPI(Application Programming Interface)公開が広がっています。また、自組織内でもモバイルアプリケーション開発やシステム間連携を行いやすくするために、システムがAPIを提供することが多くなってきています。その際、APIは限られた人やシステムにだけがアクセス可能にする必要があるため、認証・認可のようなセキュリティ技術が必須になってきます。 認証・認可は、OAuth 2.0の枠組みに基づくことが一般的ですが、OAuthは自由度が高い仕様であるため、誤って実装・構築してしまうとセキュリティホールが作りこまれてしまいます。本記事では、近年急成長を遂げている認証・認可サーバOSSである「
はじめに これまで、APIを管理する製品として、オープンソースの「3scale」について紹介してきましたが、APIのライフサイクルにはAPIを管理する前に設計・実装・デプロイ・公開といったフェーズがあります。中でもAPIでどのようなサービスや機能を提供していくかを決めるAPIの設計フェーズは、APIの価値を決める上で非常に重要なフェーズと言えます。 そこで今回は、3scaleと関連するOSS製品として、APIの設計フェーズで役立つ「Apicurio」と「Microcks」について紹介します。 APIファーストのアプローチ APIファーストのアプローチとは、クライアントアプリケーションにとってAPIが最初のインタフェースであると捉え、APIのコーディングや実装を行う前に、APIとしてどのような機能やデータを提供していくべきか、そのAPIの利用者を念頭に置いてAPIの仕様を決めることです。 A
Red Hat Summit 2019で、製品とクラウド担当のEVP、SVPにRed Hat製品の未来について語ってもらった。 Red Hat Summit 2019では、CEOのJim Whitehurst氏を始めとして多くのエグゼクティブがメディアやアナリストの質問に答えるラウンドテーブルやブリーフィングが行われた。これはプレスリリースなどで発表された内容の詳細な説明や質疑応答を行うためのもので、ここからメディアやアナリスト達は方向性や将来性などを分析することになる。当然機会があれば、1対1のインタビューを行ってさらに深い内容に切り込んでいくことになる。 今回はRed Hatの製品とテクノロジーのトップであるプロダクトとテクノロジー担当のExecutive Vice President、Paul Cormier氏のラウンドテーブルと、クラウドプラットフォームのSenior Vice P
APIとは APIは「Application Programming Interface」の略で、簡単に言うと「ソフトウェアの機能を利用する際の決まりごと」です。世の中には様々なシステムがありますが、その機能がAPIとして共有されていればそのAPIを使うことで必要な機能を利用でき、無駄に開発することなく、より効率的にソフトウェア開発ができるようになります。 例えば、Google Mapsの機能もGoogle Maps API で利用できるようになっており、その位置情報を取得する機能(ジオコード)を利用する際にはAPIの場所をURLで指定し、利用するための鍵や場所を指定するためのキーワードを渡すのが決まりごとになっています。 APIという用語自体はコンピュータの世界では幅広い概念を表す用語ですが、インターネットとWebの普及により、最近ではAPIと言った時にはWebのAPIを表すことが多くな
Red Hat Summit 2019開催。新製品のハイライトはRHELとOpenShiftの最新バージョンだ。Microsoft、VMwareからのエンドースメントにも注目したい。 Red Hat Summit 2019の目玉は、何と言ってもRed Hat Enterprise Linux(RHEL)の最新バージョン8、そしてKubernetesをベースにしたコンテナプラットフォームであるOpenShiftの最新バージョン4だ。例年Red Hat Summitのジェネラルセッションは多くの顧客が登壇し、Red Hat製品のユースケースを語ることが中心となり、あまり製品そのものの解説は行われない。製品そのもののプレゼンテーションは、ブレークアウトセッションなどで行われるのが通例だ。今回の記事では、カンファレンスに合わせて行われたプレス向けブリーフィングの内容を紹介することで、新たに発表され
Red Hat Summit 2019がボストンで開催され、最新プロダクトや新しいロゴなど、明るいニュースに満ちたカンファレンスとなった。 オープンソースのリーディングベンダーであるRed Hatが開催する年次カンファンレス、Red Hat Summit 2019がボストンで開催された。2018年10月にIBMによる買収が発表されて以降の最大規模のイベントということもあり、大きな変化があることが期待されていた。 実際のところ、何よりも主力製品であるRed Hat Enterprise Linuxの最新バージョンとなるRHEL 8、コンテナオーケストレーションのデファクトスタンダードとなったKubernetesをエンタープライズ向けに仕上げたOpenShiftの最新バージョン4、そしてOpenShiftのテンプレートを配布するOperatorHubの統合など、製品面でのニュースに事欠かないイ
はじめに 前回の記事では、APIとAPI管理の基本的なことについて説明し、オープンソースのAPI管理製品である3scaleをご紹介しました。本記事では、API管理基盤となる3scaleのインストール方法をご紹介したいと思います。 前回記事にもある通り3scaleのソースコードはGitHubで公開され、コミュニティによる開発が進められています。3scaleを構成する主要モジュールは5つ(APIcast、Porta、Apisonator、Pisoni、Zync)あり、そこで使用されるシステムコンポーネントはすべてコンテナとして動作します。3scaleをインストールできる環境には、Kubernetesをベースとしたオープンソースのコンテナ管理プラットフォームであるOpenShiftがあります。 今回は簡単にインストールできるオールインワン構成のOpenShiftであるMinishiftを使って、
連載5回目となる今回は、OpenShiftでデプロイしたアプリケーションの運用に関するトピックを紹介する。 今回は、デプロイしたアプリケーションの運用に関わる設定を中心に紹介していきたいと思います。デプロイメントのヘルスチェックの設定や環境依存情報の取り扱い、永続ストレージの設定など、デプロイメントの「チューニングポイント」といった内容です。今回紹介する機能のほとんどが、Kubernetesで実装されているものなので、すでにご存知の方もいるかもしれませんが、OpenShiftのコマンドを使った設定方法と一緒に確認していきましょう。 アプリケーションのヘルスチェック Readiness Probe と Liveness Probe Readiness ProbeとLiveness Probeは、OpenShift(Kubernetes)が提供しているアプリケーションへのヘルスチェックの機能で
KubeCon+CloudNativeCon 2日目のセッションから、Airbnbのユースケースと、クラウドネイティブ志向の言語Ballerinaを紹介する。 KubeCon+CloudNativeConの2日目の注目は、キーノートで行われたAirbnbのユースケースだろう。KubeCon Chinaでも見られた傾向として、そもそもKubernetesそのものの話はすでにピークを過ぎており、どのようなツールを使って自社のインフラストラクチャーやアプリケーション実行環境、開発環境を自動化するか? という部分に注目が集まっていた。Kubernetesは習得するためのコストが高いというのは、多くのエンジニアが認めるところだが、今回のカンファレンスでもKustomizeやTilt、Atomist、Pulumiなどのツールの解説や、自社でツールを開発しKubernetesをラップして抽象化する方法な
KubeCon初日の午後は、さまざまなセッションが実施された。その中から、Stripeによるインフラの移行に関するトピックをメインに紹介する。 2018年12月11日はKubeCon+CloudNativeConの初日であり、午前中のキーノートでは最新のプロジェクトアップデートが行われた。 KubeCon Seattle初日のキーノートはHelm、Envoy、Istio、etcdの最新情報をアップデート そして午後のキーノートではRed HatのClayton Coleman氏、GoogleのBrian Grant氏、Tim Hockin氏によるKubernetesの振り返り、CNCFのChris Aniszczyk氏によるコントリビューターアワードの発表があり、他にStripeのエンジニアJulia EvansによるKubernetesとEnvoyによるインフラストラクチャーのマイグレー
KubeCon Seattleと併催されたOpenShift Commons Gatheringで、Operator Frameworkを全面的に採用したOpenShiftの最新バージョン4.0プレビューが紹介された。 2018年12月、KubeCon+CloudNativeConがシアトルで開催された。8000人というKubeCon史上最多の参加者(そしてキャンセルを待つウェイトリストが2000人以上!)を集めて3日間の会期を終えた。 Co-located EventのOpenShift Commons Gathering このレポートでは前日に行われたCo-located Eventの1つ、Red Hatが推進するKubernetesのプラットフォームであるOpenShiftのコミュニティのイベント、「OpenShift Commons Gathering」についてお届けする。 Kub
学習と開発のための環境の選択肢 これまでの連載で、OpenShiftの概要、必要となる背景やメリット、関連技術(Kubenetes、CNCF等)、そしてRed Hatが提供するトレーニングについて説明しました。これから数回にわたり、さらにOpenShiftを深掘りし、OpenShiftの環境準備から機能詳細まで紹介します。そこで今回は、OpenShiftのはじめの一歩として、第1回にて紹介したRed Hatが提供するOpenShiftのラインナップやトレーニングツールの中から、OpenShiftの学習と開発のための環境をお手軽な順(準備時間が短い順)に3つ紹介していきます。 OpenShiftの学習環境:お手軽順 Interactive Learning Portal OpenShift Online Red Hat Container Development Kit(CDK) 1. In
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く