2017-12-12 14 views
0

私たちの目標はhttps://docs.openshift.com/container-platform/3.6/admin_solutions/user_role_mgmt.html#leveraging-default-groupsに記載されているように、 "既定のアクセス許可"を変更することです。 グループsystem:authenticated , system:authenticated:oauth, system:unauthenticated は、APIにアクセスできません。 1つのユースケースがあります:管理者グループに属していないLDAPユーザは、Webコンソールにログインできません。これもテスト方法です。そのようなOpenShiftの既定のアクセス許可を制限する方法

oadm policy remove-cluster-role-from-user basic-user system:authenticated 
oadm policy remove-cluster-role-from-user system:basic-user system:authenticated 
として

コマンド

エラーなしリターン。しかし、何の効果も見られませんでした。 oc get clusterrolebindingsoc get rolebindingsの出力は同じままであり、テストユーザーは引き続きログオンできます。

私たちは間違ったコマンドを試していますか?あるいは、さらなる行動が必要なのでしょうか?

+0

認証されたユーザーがREST APIにアクセスできないようにすると、Webコンソールまたはコマンドラインを使用できなくなります。実際に彼らは何もすることはできませんし、あなたは彼らにアカウントを与えないかもしれません。これまでに説明されているように意味がないので、これの背後にある理由は何か。 –

+0

ユーザーがデプロイしたアプリケーションは、そのユーザーとしてではなくサービスアカウントで実行されることに注意してください。その下で実行される '' default''サービスアカウントアプリケーションは、REST APIへのアクセス権を持ちません。特権を明示的に付与する必要があります。 –

答えて

0

これが働いた:

oadm policy remove-cluster-role-from-group basic-user system:authenticated 

をのでsystem:authenticatedがグループではなく、ユーザーです。それは間違った命令だった。 Red Hatサポートに感謝します。

けれども - クラスタは、上記のコマンドを実行した後に動作しませんでした、と

oadm policy remove-cluster-role-from-group basic-user system:unauthenticated 

は、我々はそれを元に戻す必要がありました。私はそれが大混乱を引き起こしたのは第二の命令だけだったのだろうかと思います。しかし、ほぼ1週間のダウンタイムの後で、残りのチームは、システムから基本ユーザーを取り消すだけで何が起こるかをテストすることに熱心ではありません。

+0

これは認証されたユーザー(オープンシフトの管理者ではないユーザー)からのプロビジョニングを行いますが、まだログオンすることができます:https://lists.openshift.redhat.com/openshift-archives/users/2016-July/msg00236 .html – ynux

関連する問題