このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
Kubernetesはさまざまな環境で利用され、かつ不特定多数がクラスタにアクセスできることを前提に構築されており、そのため非常に柔軟なユーザー認証機構やユーザーの権限を管理する機能が組み込まれている。本記事ではこれらの認証や権限確認機構がどのように働くのかや、その仕組みについて解説する。 Kubernetesにおける認証の必要性 Kubernetesはさまざまな企業・組織が参加するオープンな組織「Cloud Native Computing Foundation(CNCF)」によって開発が進められているが、元々はGoogleによってその開発がスタートしたプロジェクトであり、同社の持つコンテナクラスタ管理技術を元にしている。そのため、Kubernetesは当初から不特定多数がアクセスできるパブリッククラウドでの利用が想定されており、そういった環境でもセキュアかつ柔軟に利用できるよう設計され
はじめに 本記事では、Kubernetesで実現するマルチテナントについて、2020年9月時点での現状と、将来的に利用できるであろう機能の紹介をいたします。各機能についての詳細は、参考ドキュメント等を参照していただければと思います。 本記事の要点 マルチテナントは単一のクラスター上に複数のテナントを共存させることを指す。 Kubernetesにはマルチテナントを実現するための機能が備わっている。 アクセスコントロール:RBAC セキュリティ:Namespace / Network Policy / Pod Security Policy リソースの隔離:ResourceQuota / LimitRange / Affinity / Taintなど Kubernetesのマルチテナント機能は、SIGを中心として機能開発が進められている。 Benchmarks Tenant Controlle
RBACの基礎 業務システムの権限制御の基本形はロールベースアクセスコントロール(RBAC)です。簡単化すると、以下のようなモデルです。 Subject(システムユーザ)は、複数のRole(ロール)を持っている。 Role(ロール)は、Permission(権限)のセットからなる。 Permission(権限)は、オペレーション(許可される操作)のセットからなる 具体的に、Redmineでの例をみてみましょう。 ユーザにはデフォルトで「管理者」「開発者」「報告者」のロールが割当可能である。 「報告者」ロールは、「Add Issues」の権限をもつ。 「Add Issues」の権限をもつユーザは、「Issueの新規作成」ができる。 このモデルをRedmineでは、以下のように表現しています。 Redmineは1人のユーザを、複数のプロジェクトに異なるロールでアサインすることができるので、上記
こんにちは。EC基盤グループの宮口(@smiyaguchi)と池田(@progrhyme)です。 モノタロウではKubernetesのマネージドサービスであるGoogle Kubernetes Engine(以下、GKE)を利用しています。 このKubernetesですがとても便利な反面、管理が大変で開発者がアプリケーションの開発とKubernetesの運用を同時に行うのは負荷が高くなりあまり好ましくありません。 そこでモノタロウでは開発と運用を分離できるように、社内でGKE共通環境と呼んでいるマルチテナント方式のクラスタによるアプリケーションの実行基盤を構築しました。 今回はその紹介をします。 マルチテナント・シングルテナントとは? なぜマルチテナントのGKE環境を作ることにしたのか 全体概要 前提・環境情報 GKE共通環境の特徴 Namespace・ノードプールの分離 RBACによる権
はじめに インターンでお世話になっている、コウゲと申します。現在担当させていただいている仕事は業務で使用している管理画面のマイクロサービス化です。 マイクロサービス間をつなぐ認証機能が必要だったので、認証プラットフォームとして使いやすそうな 「Auth0」で どんなことができるのか、実現したいことは可能なのかを検証してみることになりました。 なぜAuth0なのか ダッシュボードの設定 + 少ないコード で認証機能が簡単に実装できる。 Auth0専用ライブラリやSDKが多数存在し、目的に応じてそれを利用することで 簡単にログイン機能を実装することができる。 実現したいこと 発表 ありがたいことに、調べた結果を社内で発表する場を設けていただきました。 ブログの内容より少し詳しく書いています。読んだら即実装できるようなスライドを心がけて作りました! speakerdeck.c
Amazon Verified Permissions とは 従来の認可処理 Cedar 言語の使い方 基本的な記述方法 RBAC の例 ABAC の例 golang で動かしてみる 1. ポリシーストアを AWS コンソールから作成する 3. サンプルアプリケーションの実装 最後に こんにちは、2023年5月にバックエンドエンジニアとしてジョインした yamanoi です。 最近は Cloudflare スタックに注目しており、新機能を触ったりアップデートを眺めたりしています。 今回は先日 GA (一般利用可能)になった AWS のサービス Amazon Verified Permissions を、 golang で実装した簡単なサンプルを交えて紹介したいと思います。 Amazon Verified Permissions とは Amazon Verified Permissions
すべての経済活動を、デジタル化するために、すべての業務活動を、デジタル化したいコーポレートエンジニアリング室の @yuya-takeyama です。 7月はBet Technology Monthということでブログがたくさん出てくる月です。 そして7月といえば、第二四半期の始まりですね。 今月から転職や異動によって新しい環境で働き始める方も多いのではないでしょうか。 LayerXでは毎月のように入社・異動があるため、その度にやらないといけないことがあります。 それは、各種グループのメンバーの更新です。 LayerXにおけるグループメンバーの管理 LayerXではID基盤としてMicrosoft Entra IDを利用しています。 また、SCIMプロトコルを利用した自動プロビジョニングにより、そこから各種SaaS (Google Workspace, Slack, Notion, AWS,
ポイント ●アクセス制御には,任意アクセス制御(DAC),強制アクセス制御(MAC),ロールベースのアクセス制御(RBAC)の3種類ある ●任意アクセス制御(DAC)は,オブジェクトの所有者がアクセス権限を設定する ●強制アクセス制御(MAC)は,あらかじめ設定されたレベル分けによって,強制的に読み取りや書き込みなどの権限が制限される ●ロールベースのアクセス制御(RBAC)は,ロール(役割)によって実行できる操作が制限される あるユーザーがサーバーにログインしました。しかし,そのサーバー上のすべてのリソースやサービスを利用できるわけではありません。許されている行為は,あらかじめ管理者によって決められている(=アクセス制御されている)からです。今回は,代表的な3つのアクセス制御方式を見ていきましょう。代表的な3つのアクセス制御方式とは,任意アクセス制御(DAC),強制アクセス制御(MAC)
ロールベースアクセス制御(英: Role-based access control, RBAC)[1][2]は、認められたユーザーのシステムアクセスを制限するコンピュータセキュリティの手法の一種。強制アクセス制御 (MAC) や任意アクセス制御 (DAC) よりも新しい手法である。 概要[編集] RBAC は、ポリシーを柔軟に設定できるアクセス制御法であって、任意アクセス制御 (DAC)[3]も強制アクセス制御 (MAC)[4]もシミュレート可能である。 RBAC が開発されるまで、アクセス制御法としては MAC と DAC しかなかった。従って、MAC を使っていないなら DAC を、DAC を使っていないなら MAC を使っていると思ってほぼ間違いなかった。90年代後半の研究では、RBAC はそのどちらにも分類されていない[要出典]。 組織において、「ロール(役割)」とは仕事上の機能を
RBACとは RBAC(Role-based access control)とは、役割ベースのアクセス制御機能。 RBACリソースは4つのリソースがある。RoleリソースとClusterRoleリソースとRoleBindingリソースとClusterRoleBindingリソース。 RoleとClusterRoleは、どのリソースにどんな操作を許可するかを定義するためのリソース RoleBindingとClusterRoleBindingはどのRole/ClusterRoleをどのUserやServiceAcctountに紐付けるかを定義するためのリソース。 ユーザは以下のようにkubectl config set-credentialsを使って作成できる kubectl config set-credentials alice --username=alice --password=pa
今回のポストは「適切に運用された Entra ID テナント上で、適切に運用された組織アカウントで開発をしている方」や Entra ID テナントの闇(テナント複数あったりマイクロソフトアカウントが入り混じったり)に触れたことのない人には縁のない話です。この文章だけで痛みが分かる方には有益な情報を追記したつもりなので、引き続き通読してください。「タイトルみたいな複雑な運用するのが間違っている」という方へのアドバイスはこちらになります。 君はマトモな職場に居るか、マトモに仕事した事が無いんだね こっちに来てはいけないよ、森にお帰り。— ロリ=デカパイスキー3世 (@sumatora) June 27, 2022 今回私がハマった元ネタは以下の記事に記載のある「Cosmos DB へのデータアクセスを RBAC で制御しようとした」です。本来はハマりどころは大してないのですが、掲題の件が絡むと
Code Archive Skip to content Google About Google Privacy Terms
KubernetesのRBAC(Role-based access control)の設定用にAPIリソースについてまとめました。Kubernetes v1.4時点での情報になります。 KubernetesのAPI KubernetesのAPIは、API ResourceとNon-Resource URLの2つに分けられます。 API Resource Kubernetes上で扱われる情報(Pod, Service等)はapiserver上ではAPI Resourceとして定義されています。kube-schedulerやkubelet、kubectlなどKubernetesのコンポーネントはこのAPIリソースをHTTPで操作することでPodの配置などの実際の操作を行います。(参考: Kubernetes: コンテナが起動するまでの各コンポーネントの流れ パスの形式例(requestinfo
Azure サブスクリプションは、Microsoft Entra テナント との間に信頼関係があります。 サブスクリプションはこのテナント (ディレクトリ) に依存して、セキュリティ プリンシパルとデバイスの認証と承認を行います。 サブスクリプションの有効期限が切れると、信頼されたインスタンスは残りますが、セキュリティ プリンシパルでは、Azure リソースへのアクセスが失われます。 サブスクリプションは 1 つのディレクトリのみを信頼できます (関連付けられる) が、1 つの Microsoft Entra テナントは複数のサブスクリプションから信頼されることができます。 ユーザーが Microsoft のクラウド サービスに新規登録すると、新しい Microsoft Entra テナントが作成され、そのユーザーがグローバル管理者となります。 ただし、サブスクリプションの所有者が自分のサ
There were quite a few words on the death of Linux on the desktop lately, ... Why Built-In Optical Drives and HDDs No Longer Make Sense The Human Wildcard 6 Cheaper Superphones You Probably Didn’t Know About 7 Fun Yet Productive Ways to Kill Boredom on The Internet
このページに記載されている情報は古い可能性があります このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: Using RBAC Authorization Role Based Access Control(RBAC)は、組織内の個々のユーザーのRoleをベースに、コンピューターまたはネットワークリソースへのアクセスを制御する方法です。 RBAC認可はAPIグループ rbac.authorization.k8s.ioを使用して認可の決定を行い、Kubernetes APIを介して動的にポリシーを構成できるようにします。 RBACを有効にするには、以下の例のようにAPI serverの--authorization-mode フラグをコンマ区切りのRBACを含むリストでスタートします。
イーゲルは、Linuxカーネルや 国際標準技術の見識をもった、 スペシャリストを中心とした 技術者グループです。 イーゲルは、Linuxカーネルや 国際標準技術の見識をもった、 スペシャリストを中心とした 技術者グループです。 私たちイーゲルは、コンピュータ・サイエンスを、 "人と人がつながり、互いに理解し合うための「道具」"だと考えています。 本来、コンピュータ・サイエンスは、理論と実績が重視される学問ですが、 残念ながら、現状ではその理論が実践の場で必ずしも活かされていないと考えています。 コンピュータ・サイエンスを学術的に探求しつつ、 人々を幸せにする実践的な「道具」をつくり続けていくことで社会に貢献する。 イーゲルは、そんなエンジニア集団を目指しています。
Azure を初めて使用する場合、Azure のさまざまなロールを理解することは少し難しいかもしれません。 この記事では、以下のロールと、それぞれをどのような場合に使用するかについて説明します。 Azure ロール Microsoft Entra ロール 従来のサブスクリプション管理者ロール 各ロールの関係 Azure のロールをよりよく理解するには、歴史の一部を知ることが役立ちます。 Azure が最初にリリースされたとき、リソースへのアクセスは次の 3 つの管理者ロールで管理されました:アカウント管理者、サービス管理者、共同管理者。 その後、Azure ロールベースのアクセス制御 (Azure RBAC) が追加されます。 Azure RBAC は、Azure リソースに対するきめ細かいアクセス管理を提供する、より新しい承認システムです。 Azure RBAC には多数の組み込みロール
ユーザーに一部のコマンドだけをroot権限(あるいはそのほかの特定のアカウントの権限)で実行させたいという場合に用いられる便利なフリーソフトにsudoがある。しかし、Solaris 8以降ではRBAC(Role Based Access Control)に含まれる機能で、ほぼ同様のことが実現できる。 Solaris 9の場合について、具体的な方法について説明する。なおRBACの全体像については、「Solarisのシステム管理(セキュリティサービス)」中の 17. 役割によるアクセス制御(概要) 18. 役割によるアクセス制御(手順) 19. 役割によるアクセス制御(参照) を参照してほしい。 以下、説明のため、/usr/bin/idをmonyoというアカウントに限り、uid=0/gid=0で実行する場合を例に取り、具体的な設定方法を示す。 (1)/etc/security/prof_att
Kubernetes: v1.6 の Role-Based Access Control (RBAC) を minikube で試すkubernetes Kubernetes 1.6 で Role-Based Access Control (RBAC) が beta になり、デフォルトのロールの拡充や kubectl からロールの紐付けができるようになったりと大幅にアップデートされました 。以下は v1.6 の RBAC と minikube で試す際のメモになります。 v 1.6 での RBAC の主な変更点 デフォルトロールの拡充。汎用的に使える読み取り専用ロール (view) や 書き込み権限ロール (edit) などが用意されました。 kubectl のサブコマンド create rolebinding/clusterrolebinding が追加され簡単にロールの紐付けができるよ
Relationship-based access control made fast, scalable, and easy to use.OpenFGA is an open-source authorization solution that allows developers to build granular access control using an easy-to-read modeling language and friendly APIs. Quick StartTrying OpenFGA is as easy as... Run the following snippet in a terminal in an environment with Docker installed: OpenFGA will be running at localhost:8080
Kubernetes v1.7 で導入された Node Authorization について概要と kubeadm で構築して試してみた結果をまとめました。確認は Kubernetes v1.7.0 で行っています。 概要 Node Authorization とは Node (Kubelet) の権限管理をより厳密に行う機能です。この機能を有効にすることで、Node はその Node が関連するオブジェクトにのみ権限が制限されるようになります。例えば Node は割り当てられた Pod が参照する Secret 以外にはアクセスできなくなります。これにより Node のクレデンシャルが漏洩したときのセキュリティリスクを最小限にすることができます。 制限されるリソース Node Authorization を有効にすると Node がアクセスする必要があるリソースをその Node に関連あ
Introduction¶ Flask-Principal provides a very loose framework to tie in providers of two types of service, often located in different parts of a web application: For example, an authentication provider may be oauth, using Flask-OAuth and the user information may be stored in a relational database. Looseness of the framework is provided by using signals as the interface. The major components are th
This article's lead section may be too short to adequately summarize the key points. Please consider expanding the lead to provide an accessible overview of all important aspects of the article. (May 2012) In computer systems security, role-based access control (RBAC)[1][2] or role-based security[3] is an approach to restricting system access to authorized users, and to implementing mandatory acce
Azure ロールベースのアクセス制御 (Azure RBAC) には、ユーザー、グループ、サービス プリンシパル、マネージド ID に割り当てることのできる Azure 組み込みロールがいくつかあります。 ロールの割り当ては、Azure リソースへのアクセスを制御する方法です。 組み込みロールが組織の特定のニーズを満たさない場合は、独自の Azure カスタム ロールを作成することができます。 ロールの割り当て方法については、「Azure ロールを割り当てる手順」を参照してください。 この記事では、Azure 組み込みロールを一覧で示します。 Microsoft Entra ID の管理者ロールをお探しの場合は、「microsoft Entra 組み込みロールを参照してください。 次の表に、各組み込みロールの簡単な説明を示します。 ロール名をクリックすると、各ロールの Actions、N
Philosophy We strive to create an environment conducive to many different types of research across many different time scales and levels of risk. Learn more about our Philosophy Learn more
そんなわけでAKSのTipsその2です。今回はRBACメインで。 AKS Tips 1 Overview RBACはRole-Based Access Control(ロールベースのアクセス制御)の略ですね。 Azureには各リソースに対してRBACの仕組みがあります。同様にk8sにもRBACの仕組みがあります。概念的にはだいたい同じでk8sのAPIを使用する際にユーザーのロールに応じてアクセス可否を判断することができます。 今回のPostはAzure AD (OpenID Connect)との認証連携とk8sでのRBACについてのメモになります。k8sで利用可能な他の認証方式(証明書認証とか)や認可の仕組みについては割愛します。 とりあえず以下のドキュメント参照で。 Azure Active Directory と AKS を統合する – プレビュー Kubernetes – Authe
はじめに この記事はReactのサンプルアプリケーションにRBAC(Role Based Access Control)を実装する手順で、こちらの原文を元に作成しています。ソースコードに"もしロールがxxだったらxxする"と実装しがちですが、この記事では要件やロールが変わっても柔軟に対応できてステップ数も少なくメンテナンス性の高い方法で実装しています。nodeとnpmのインストール、Auth0の無料アカウントの取得とテナントの作成が完了していることが前提となっています。まだの方はこちらの記事を参照の上ご準備をお願いします。 完成版のソースコードはここで公開しています。 環境 OS : macOS Mojave 10.14.6 node : 10.15.3 npm : 6.10.3 手順 アプリケーションの作成 任意のディレクトリでnpxを実行してnpmのバイナリを実行します。
Athenz(アセンズ)は、Role Based Access Control(ロールを利用したアクセス制御)を利用して、サービス間の認証・認可を行うシステムです。 旧Yahoo! Inc.にて開発されたシステムであり、2017年にOSS化されました。 2021年1月にはCNCF Sandboxプロダクトとなり、活発に開発が行われています。 Athenz 当社では2015年からAthenzを利用しており、2017年のOSS化にも貢献しています。 社内では多くのアプリケーションが稼働し、それぞれがAPI連携にてデータのやりとりをしています。それらのアプリケーション間の認証・認可の基盤システムとしてAthenzを活用し、当社が提供するサービスのセキュリティ向上に寄与しています。 社内にて利用してきた実績をもとに、Athenzへの改善提案・関連プロダクトの開発・提供や、各種カンファレンスにて社内
Role-based access control (RBAC) refers to the idea of assigning permissions to users based on their role within an organization. It offers a simple, manageable approach to access management that is less prone to error than assigning permissions to users individually. When using RBAC for Role Management, you analyze the needs of your users and group them into roles based on common responsibilities
ActiveRbac is a Ruby On Rails plugin that supports you in implementing Role Based Access Control (RBAC) in your application. Getting active-rbac At the moment, active-rbac is being rewritten. The new version - to be named 0.5.0 - is currently only available from SVN trunk. $> cd $RAILS_ROOT $> svn co svn://rubyforge.org/var/svn/active-rbac/active-rbac/trunk/plugin \ vendor/plugins/active-rbac Ther
Role-based Access Control は、ユーザと許可とを直接紐付けるのではなく、間に役割(Role)を挟みこんだ 3 段階の権限管理を行っています; 誰が何をできるか?という設定は緻密で具体的ではありますが、その繊細さゆえに設定ミスを誘発しがちになります。Role を挟むことにより、「その役割の人なら、これらの振る舞いが認可される」という関係性を定義することができるようになります。 たとえば異動したユーザに対して、許可をひとつひとつ剥がしてひとつひとつ付け直すよりも、役割を 1 つだけ付け直すほうが、明らかにミスが減りますよね。 セットアップ何を作るか?投稿管理システムを素振りしてみます。役割として「ビジター」「執筆者」「管理者」の 3 種類を想定し、それぞれの役割に応じて閲覧や操作の許可をコントロールできる機能を実装していきます; このスクリーンショットの場合は、執筆者
Azure RBAC カスタム ロールの定義「Actions」と「NotActions」に全く同一の管理操作が定義された場合の動作についてAzureAzureADRBAC はじめに Azure RBAC (ロールベースのアクセス制御) は、できることがとても多いので 1 つの記事ですべての RBAC の内容を網羅することは到底不可能な為、今回はタイトルに記載の動作に的を絞って検証をしてみました。 そもそも RBAC って何?っていう話もあるかと思いますが、RBAC に関する基本的な内容を押さえるには下記 Microsoft Learn の内容が非常によく出来ているので、ぜひ一度学んでみていただけると良いかと思います。 -Microsoft Learn ロールベースのアクセス制御 (RBAC) を使用して Azure リソースのカスタム ロールを作成する この Microsoft Learn
Azure portal を使用して BLOB データにアクセスするときに、ポータルでは内部的に Azure Storage への要求が発行されます。 Azure Storage への要求は、Microsoft Entra アカウントまたはストレージ アカウント アクセス キーのいずれかを使用して承認できます。 ポータルでは、どの方法を使用しているかを示し、適切なアクセス許可がある場合は、それら 2 つを切り替えることができます。 また、Azure portal で個々の BLOB アップロード操作を承認する方法を指定することもできます。 既定では、ユーザーが BLOB アップロード操作を承認するために既に使用している任意の方法がポータルによって使用されますが、BLOB をアップロードするときにこの設定を変更できます。 BLOB データにアクセスするために必要なアクセス許可 Azure p
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く