twitter icon linked-in icon youtube icon

Cassandra ドキュメント

バージョン

5.0

プレリリースバージョンのドキュメントを表示しています。

データベースロール

CQLは、ユーザーとユーザーグループを表すためにデータベースロールを使用します。構文的には、ロールは次のように定義されます。

role_name ::= identifier | string

CREATE ROLE

ロールの作成には、CREATE ROLEステートメントを使用します。

create_role_statement ::= CREATE ROLE [ IF NOT EXISTS ] role_name
                          [ WITH role_options# ]
role_options ::= role_option ( AND role_option)*
role_option ::= PASSWORD '=' string
                | HASHED PASSWORD '=' string
                | LOGIN '=' boolean
                | SUPERUSER '=' boolean
                | OPTIONS '=' map_literal
                | ACCESS TO DATACENTERS set_literal
                | ACCESS TO ALL DATACENTERS
                | ACCESS FROM CIDRS set_literal
                | ACCESS FROM ALL CIDRS

例えば

CREATE ROLE new_role;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
CREATE ROLE alice WITH HASHED PASSWORD = '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' AND LOGIN = true;
CREATE ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
CREATE ROLE carlos WITH OPTIONS = { 'custom_option1' : 'option1_value', 'custom_option2' : 99 };
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO DATACENTERS {'DC1', 'DC3'};
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO ALL DATACENTERS;
CREATE ROLE bob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1', 'region2' };
CREATE ROLE hob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;

デフォルトでは、ロールにはLOGIN権限またはSUPERUSERステータスがありません。

権限は、データベースリソース（keyspace、テーブル、関数、ロール自体など）に付与されます。ロールは他のロールに付与して階層的な権限構造を作成できます。これらの階層では、権限とSUPERUSERステータスは継承されますが、LOGIN権限は継承されません。

ロールにLOGIN権限がある場合、クライアントは接続時にそのロールとして識別できます。その接続中は、クライアントはそのロールに付与されたすべてのロールと権限を取得します。

クライアントがSUPERUSERでない限り、データベースロールリソースに対するCREATE権限を持つクライアントのみがCREATE ROLEリクエストを発行できます（関連セクションを参照）。Cassandraでのロール管理はプラグイン可能であり、カスタム実装では、リストされているオプションの一部のみをサポートする場合があります。

ロール名に英数字以外の文字が含まれている場合は、引用符で囲む必要があります。

内部認証の資格情報の設定

内部認証のパスワードを設定するには、WITH PASSWORD句を使用し、パスワードを単一引用符で囲みます。

内部認証が設定されていない場合、またはロールにLOGIN権限がない場合、WITH PASSWORD句は必要ありません。

jBcryptハッシュパスワードを直接提供するには、WITH HASHED PASSWORDを使用します。hash_passwordツールを参照してください。

特定のデータセンターへの接続の制限

network_authorizerが設定されている場合、ACCESS TO DATACENTERS句と、ユーザーがアクセスできるデータセンターのセットリテラルを使用して、ログインロールを特定のデータセンターに制限できます。データセンターを指定しないと、暗黙的にすべてのデータセンターへのアクセスが許可されます。ACCESS TO ALL DATACENTERS句は明示的に使用できますが、機能的な違いはありません。

特定のCIDRグループからの接続の制限

cidr_authorizerが設定されている場合、ACCESS FROM CIDRS句と、ユーザーがアクセスできるCIDRグループのセットリテラルを使用して、特定のリージョン（CIDRグループ）からのみログインするようにロールを制限できます。CIDRグループを指定しないと、暗黙的にすべてのCIDRグループからのアクセスが許可されます。ACCESS FROM ALL CIDRS句は明示的に使用できますが、機能的な違いはありません。この句を使用して、CIDRグループの制限を削除することもできます。有効なCIDRグループは、ACCESS FROM CIDRS句で使用してください。nodetool list-cidrgroupsコマンドを使用して、クラスタで使用可能なCIDRグループを確認できます。

条件付きロールの作成

IF NOT EXISTSオプションを使用しない限り、既存のロールを作成しようとすると、無効なクエリ条件になります。このオプションを使用していて、ロールが存在する場合は、ステートメントはno-opになります。

CREATE ROLE other_role;
CREATE ROLE IF NOT EXISTS other_role;

ALTER ROLE

ロールオプションの変更には、ALTER ROLEステートメントを使用します。

alter_role_statement ::= ALTER ROLE [ IF EXISTS ] role_name WITH role_options

例えば

ALTER ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
ALTER ROLE bob WITH HASHED PASSWORD = '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' AND SUPERUSER = false;
ALTER ROLE rob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;
ALTER ROLE hob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1' };

ロールが存在しない場合、IF EXISTSを使用しない限り、ステートメントはエラーを返します。その場合、操作はno-opになります。

jBcryptハッシュパスワードを直接提供するには、WITH HASHED PASSWORDを使用します。hash_passwordツールを参照してください。

特定のデータセンターへの接続の制限

network_authorizerが設定されている場合、ACCESS TO DATACENTERS句と、ユーザーがアクセスできるデータセンターのセットリテラルを使用して、ログインロールを特定のデータセンターに制限できます。データセンターの制限を削除するには、ACCESS TO ALL DATACENTERS句を使用します。

特定のCIDRグループからの接続の制限

cidr_authorizerが設定されている場合、ACCESS FROM CIDRS句と、ユーザーがアクセスできるCIDRグループのセットリテラルを使用して、特定のリージョン（CIDRグループ）からのみログインするようにロールを制限できます。CIDRグループを指定しないと、暗黙的にすべてのCIDRグループからのアクセスが許可されます。ACCESS FROM ALL CIDRS句は明示的に使用できますが、機能的な違いはありません。この句を使用して、CIDRグループの制限を削除することもできます。有効なCIDRグループは、ACCESS FROM CIDRS句で使用してください。nodetool list-cidrgroupsコマンドを使用して、クラスタで使用可能なCIDRグループを確認できます。

ALTER ROLEステートメントの実行条件

  • クライアントは、別のロールのSUPERUSERステータスを変更するには、SUPERUSERステータスが必要です。

  • クライアントは、現在保持しているロールのSUPERUSERステータスを変更できません。

  • クライアントは、ログイン時に識別されたロールの一部のプロパティのみを変更できます（例：PASSWORD）。

  • ロールのプロパティを変更するには、クライアントにそのロールに対するALTER 権限が付与されている必要があります。

DROP ROLE

ロールの削除には、DROP ROLEステートメントを使用します。

drop_role_statement ::= DROP ROLE [ IF EXISTS ] role_name

DROP ROLEには、クライアントに問題のロールに対するDROP 権限が必要です。さらに、クライアントはログイン時に識別されたロールをDROPできません。最後に、SUPERUSERステータスを持つクライアントのみが、別のSUPERUSERロールをDROPできます。

IF EXISTSオプションを使用しない限り、存在しないロールを削除しようとすると、無効なクエリ条件になります。このオプションを使用していて、ロールが存在しない場合は、ステートメントはno-opになります。

DROP ROLEは、意図的に開いているユーザーセッションを終了しません。接続されているセッションは接続されたままであり、認証を必要としないデータベースアクションを実行する機能を保持します。ただし、認証が有効になっている場合、削除されたロールの権限も、cassandra-yamlファイルで設定されたキャッシュオプションに従って取り消されます。削除されたロールが後で再作成され、新しい権限またはロールが付与された場合、接続されたままのクライアントセッションは、新しく付与された権限とロールを取得します。

GRANT ROLE

ロールを別のロールに付与するには、GRANT ROLEステートメントを使用します。

grant_role_statement ::= GRANT role_name TO role_name

例えば

GRANT report_writer TO alice;

このステートメントは、report_writerロールをaliceに付与します。report_writerに付与された権限は、aliceも取得します。

ロールは有向非巡回グラフとしてモデル化されているため、循環的な付与は許可されません。次の例はエラー条件になります。

GRANT role_a TO role_b;
GRANT role_b TO role_a;

GRANT role_a TO role_b;
GRANT role_b TO role_c;
GRANT role_c TO role_a;

REVOKE ROLE

ロールの取り消しには、REVOKE ROLEステートメントを使用します。

revoke_role_statement ::= REVOKE role_name FROM role_name

例えば

REVOKE report_writer FROM alice;

このステートメントは、aliceからreport_writerロールを取り消します。aliceがreport_writerロールを通じて取得した権限も取り消されます。

LIST ROLES

既知のすべてのロール（システム内のロールまたは特定のロールに付与されたロール）は、LIST ROLESステートメントを使用してリストできます。

list_roles_statement ::= LIST ROLES [ OF role_name] [ NORECURSIVE ]

例えば

LIST ROLES;

システム内のすべての既知のロールを返します。これには、データベースロールリソースに対するDESCRIBE権限が必要です。

この例では、推移的に取得されたロールを含めて、aliceに付与されたすべてのロールが列挙されます。

LIST ROLES OF alice;

この例では、推移的に取得されたロールを含めずに、bobに直接付与されたすべてのロールがリストされます。

LIST ROLES OF bob NORECURSIVE;

ユーザー

Cassandra 2.2でロールが導入される前は、認証と認可はUSERの概念に基づいていました。後方互換性のために、レガシー構文は保持されており、USER中心のステートメントは、ROLEベースの等価物と同義語になっています。つまり、ユーザーの作成/更新は、ロールの作成/更新とは異なる構文にすぎません。

CREATE USER

ユーザーの作成には、CREATE USERステートメントを使用します。

create_user_statement ::= CREATE USER [ IF NOT EXISTS ] role_name
                          [ WITH [ HASHED ] PASSWORD string ]
                          [ user_option ]
user_option: SUPERUSER | NOSUPERUSER

例えば

CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE USER bob WITH PASSWORD 'password_b' NOSUPERUSER;
CREATE USER bob WITH HASHED PASSWORD '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' NOSUPERUSER;

CREATE USERコマンドは、LOGINオプションがtrueであるCREATE ROLEと同等です。そのため、次のステートメントのペアは同等です。

CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;

CREATE USER IF NOT EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE IF NOT EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;

CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = false;

CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;

CREATE USER alice WITH PASSWORD 'password_a';
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;

CREATE ROLE rob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;
CREATE ROLE hob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1' };

ALTER USER

ユーザーのオプションの変更には、ALTER USERステートメントを使用します。

alter_user_statement ::= ALTER USER [ IF EXISTS ] role_name [ WITH [ HASHED ] PASSWORD string] [ user_option]

ロールが存在しない場合、IF EXISTSを使用しない限り、ステートメントはエラーを返します。その場合、操作はno-opになります。例えば

ALTER USER alice WITH PASSWORD 'PASSWORD_A';
ALTER USER alice WITH HASHED PASSWORD '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
ALTER USER bob SUPERUSER;

DROP USER

ユーザーの削除には、DROP USER ステートメントを使用します。

drop_user_statement ::= DROP USER [ IF EXISTS ] role_name

LIST USERS

既存のユーザーは、LIST USERS ステートメントを使用して一覧表示できます。

list_users_statement::= LIST USERS

このステートメントはLIST ROLESと等価ですが、出力には`LOGIN`権限を持つロールのみが含まれます。

データ制御

権限

リソースに対する権限はロールに付与されます。Cassandraにはいくつかの異なるタイプのリソースがあり、各タイプは階層的にモデル化されています。

  • データリソース、Keyspace、テーブルの階層構造は、ALL KEYSPACES → KEYSPACE → TABLEです。

  • 関数リソースの構造は、ALL FUNCTIONS → KEYSPACE → FUNCTIONです。

  • ロールを表すリソースの構造は、ALL ROLES → ROLEです。

  • MBean/MXBeanのセットにマップされるJMX ObjectNameを表すリソースの構造は、ALL MBEANS → MBEANです。

権限はこれらの階層の任意のレベルで付与でき、下位に伝播します。そのため、上位のリソースに対する権限を付与すると、下位のリソースすべてに自動的に同じ権限が付与されます。例えば、KEYSPACEに対するSELECT権限を付与すると、そのKEYSPACE内のすべてのTABLEに自動的にSELECT権限が付与されます。同様に、ALL FUNCTIONSに対する権限を付与すると、どのKeyspaceにスコープされているかに関係なく、定義されているすべての関数に権限が付与されます。特定のKeyspaceにスコープされたすべての関数に権限を付与することも可能です。

権限の変更は既存のクライアントセッションに表示されます。つまり、権限の変更後、接続を再確立する必要はありません。

使用可能な権限の完全なセットは次のとおりです。

  • CREATE

  • ALTER

  • DROP

  • SELECT

  • MODIFY

  • AUTHORIZE

  • DESCRIBE

  • EXECUTE

  • UNMASK

  • SELECT_MASKED

すべての権限がすべてのリソースタイプに適用されるわけではありません。たとえば、EXECUTEは関数またはmbeanのコンテキストでのみ関連性があり、テーブルを表すリソースにEXECUTEを付与しても意味がありません。適用できないリソースに権限をGRANTしようとすると、エラー応答が発生します。以下は、どのタイプのリソースにどの権限を付与できるか、そしてその権限によってどのステートメントが有効になるかを示しています。

権限 リソース 操作

CREATE

ALL KEYSPACES

任意のKeyspaceでのCREATE KEYSPACEとCREATE TABLE

CREATE

KEYSPACE

指定されたKeyspaceでのCREATE TABLE

CREATE

ALL FUNCTIONS

任意のKeyspaceでのCREATE FUNCTIONとCREATE AGGREGATE

CREATE

ALL FUNCTIONS IN KEYSPACE

指定されたKeyspaceでのCREATE FUNCTIONとCREATE AGGREGATE

CREATE

ALL ROLES

CREATE ROLE

ALTER

ALL KEYSPACES

任意のKeyspaceでのALTER KEYSPACEとALTER TABLE

ALTER

KEYSPACE

指定されたKeyspaceでのALTER KEYSPACEとALTER TABLE

ALTER

TABLE

ALTER TABLE

ALTER

ALL FUNCTIONS

CREATE FUNCTIONとCREATE AGGREGATE：既存のものを置き換える

ALTER

ALL FUNCTIONS IN KEYSPACE

CREATE FUNCTIONとCREATE AGGREGATE：指定されたKeyspaceで既存のものを置き換える

ALTER

FUNCTION

CREATE FUNCTIONとCREATE AGGREGATE：既存のものを置き換える

ALTER

ALL ROLES

任意のロールに対するALTER ROLE

ALTER

ROLE

ALTER ROLE

DROP

ALL KEYSPACES

任意のKeyspaceでのDROP KEYSPACEとDROP TABLE

DROP

KEYSPACE

指定されたKeyspaceでのDROP TABLE

DROP

TABLE

DROP TABLE

DROP

ALL FUNCTIONS

任意のKeyspaceでのDROP FUNCTIONとDROP AGGREGATE

DROP

ALL FUNCTIONS IN KEYSPACE

指定されたKeyspaceでのDROP FUNCTIONとDROP AGGREGATE

DROP

FUNCTION

DROP FUNCTION

DROP

ALL ROLES

任意のロールに対するDROP ROLE

DROP

ROLE

DROP ROLE

SELECT

ALL KEYSPACES

任意のテーブルに対するSELECT

SELECT

KEYSPACE

指定されたKeyspace内の任意のテーブルに対するSELECT

SELECT

TABLE

指定されたテーブルに対するSELECT

SELECT

ALL MBEANS

任意のmbeanに対するgetterメソッドの呼び出し

SELECT

MBEANS

ワイルドカードパターンに一致する任意のmbeanに対するgetterメソッドの呼び出し

SELECT

MBEAN

名前付きmbeanに対するgetterメソッドの呼び出し

MODIFY

ALL KEYSPACES

任意のテーブルに対するINSERT、UPDATE、DELETE、TRUNCATE

MODIFY

KEYSPACE

指定されたKeyspace内の任意のテーブルに対するINSERT、UPDATE、DELETE、TRUNCATE

MODIFY

TABLE

指定されたテーブルに対するINSERT、UPDATE、DELETE、TRUNCATE

MODIFY

ALL MBEANS

任意のmbeanに対するsetterメソッドの呼び出し

MODIFY

MBEANS

ワイルドカードパターンに一致する任意のmbeanに対するsetterメソッドの呼び出し

MODIFY

MBEAN

名前付きmbeanに対するsetterメソッドの呼び出し

AUTHORIZE

ALL KEYSPACES

任意のテーブルに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

KEYSPACE

指定されたKeyspace内の任意のテーブルに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

TABLE

指定されたテーブルに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

ALL FUNCTIONS

任意の関数に対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

ALL FUNCTIONS IN KEYSPACE

指定されたKeyspaceでのGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

FUNCTION

指定された関数に対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

ALL MBEANS

任意のmbeanに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

MBEANS

ワイルドカードパターンに一致する任意のmbeanに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

MBEAN

名前付きmbeanに対するGRANT PERMISSIONとREVOKE PERMISSION

AUTHORIZE

ALL ROLES

任意のロールに対するGRANT ROLEとREVOKE ROLE

AUTHORIZE

ROLES

指定されたロールに対するGRANT ROLEとREVOKE ROLE

DESCRIBE

ALL ROLES

すべてのロール、または別の指定されたロールに付与されたロールのみに対するLIST ROLES

DESCRIBE

ALL MBEANS

プラットフォームのMBeanServerから任意のmbeanに関するメタデータを取得する

DESCRIBE

MBEANS

プラットフォームのMBeanServerからワイルドカードパターンに一致する任意のmbeanに関するメタデータを取得する

DESCRIBE

MBEAN

プラットフォームのMBeanServerから名前付きmbeanに関するメタデータを取得する

EXECUTE

ALL FUNCTIONS

任意の関数を使用したSELECT、INSERT、UPDATE、およびCREATE AGGREGATEでの任意の関数の使用

EXECUTE

ALL FUNCTIONS IN KEYSPACE

指定されたKeyspace内の任意の関数を使用したSELECT、INSERT、UPDATE、およびKeyspace内の任意の関数のCREATE AGGREGATEでの使用

EXECUTE

FUNCTION

指定された関数を使用したSELECT、INSERT、UPDATE、およびCREATE AGGREGATEでのその関数の使用

EXECUTE

ALL MBEANS

任意のmbeanに対する操作の実行

EXECUTE

MBEANS

ワイルドカードパターンに一致する任意のmbeanに対する操作の実行

EXECUTE

MBEAN

名前付きmbeanに対する操作の実行

UNMASK

ALL KEYSPACES

任意のテーブルのマスクされた列のクリアなコンテンツを参照する

UNMASK

KEYSPACE

Keyspace内の任意のテーブルのマスクされた列のクリアなコンテンツを参照する

UNMASK

TABLE

指定されたテーブルのマスクされた列のクリアなコンテンツを参照する

SELECT_MASKED

ALL KEYSPACES

任意のテーブルでマスクされた列を制限するSELECT

SELECT_MASKED

KEYSPACE

指定されたKeyspace内の任意のテーブルでマスクされた列を制限するSELECT

SELECT_MASKED

TABLE

指定されたテーブルでマスクされた列を制限するSELECT

GRANT PERMISSION

権限の付与には、GRANT PERMISSIONステートメントを使用します。

grant_permission_statement ::= GRANT permissions ON resource TO role_name
permissions ::= ALL [ PERMISSIONS ] | permission [ PERMISSION ]
permission ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE | EXECUTE | UNMASK | SELECT_MASKED
resource ::=    ALL KEYSPACES
                | KEYSPACE keyspace_name
                | [ TABLE ] table_name
                | ALL ROLES
                | ROLE role_name
                | ALL FUNCTIONS [ IN KEYSPACE keyspace_name ]
                | FUNCTION function_name '(' [ cql_type( ',' cql_type )* ] ')'
                | ALL MBEANS
                | ( MBEAN | MBEANS ) string

例えば

GRANT SELECT ON ALL KEYSPACES TO data_reader;

この例では、data_readerロールを持つユーザーに、すべてのKeyspaceのすべてのテーブルに対してSELECTステートメントを実行する権限を与えます。

GRANT MODIFY ON KEYSPACE keyspace1 TO data_writer;

data_writerロールを持つユーザーに、keyspace1 Keyspaceのすべてのテーブルに対してUPDATE、INSERT、UPDATE、DELETE、TRUNCATEクエリを実行する権限を与えるには

GRANT DROP ON keyspace1.table1 TO schema_owner;

schema_ownerロールを持つユーザーに、特定のkeyspace1.table1をDROPする権限を与えるには

GRANT EXECUTE ON FUNCTION keyspace1.user_function( int ) TO report_writer;

このコマンドは、report_writerロールを持つユーザーに、関数keyspace1.user_function( int )を使用するSELECT、INSERT、UPDATEクエリを実行する権限を与えます。

GRANT DESCRIBE ON ALL ROLES TO role_admin;

これにより、role_adminロールを持つユーザーに、LIST ROLESステートメントを使用してシステム内のすべてのロールを表示する権限が付与されます。

GRANT ALL

GRANT ALL形式が使用されると、ターゲットリソースに基づいて適切な権限セットが自動的に決定されます。

自動的な権限付与

CREATE KEYSPACE、CREATE TABLE、CREATE FUNCTION、CREATE AGGREGATE、またはCREATE ROLEステートメントによってリソースが作成されると、作成者（ステートメントを発行したデータベースユーザーとして識別されるロール）には、新しいリソースに対して適用可能なすべての権限が自動的に付与されます。

REVOKE PERMISSION

ロールから権限を取り消すには、REVOKE PERMISSIONステートメントを使用します。

revoke_permission_statement ::= REVOKE permissions ON resource FROM role_name

例えば

REVOKE SELECT ON ALL KEYSPACES FROM data_reader;
REVOKE MODIFY ON KEYSPACE keyspace1 FROM data_writer;
REVOKE DROP ON keyspace1.table1 FROM schema_owner;
REVOKE EXECUTE ON FUNCTION keyspace1.user_function( int ) FROM report_writer;
REVOKE DESCRIBE ON ALL ROLES FROM role_admin;

通常のドライバ操作における機能のため、特定のテーブルではSELECT権限を取り消すことができません。次のテーブルは、割り当てられたロールに関係なく、すべての承認済みユーザーが使用できます。

* `system_schema.keyspaces`
* `system_schema.columns`
* `system_schema.tables`
* `system.local`
* `system.peers`

LIST PERMISSIONS

付与された権限の一覧表示には、LIST PERMISSIONSステートメントを使用します。

list_permissions_statement ::= LIST permissions [ ON resource] [ OF role_name[ NORECURSIVE ] ]

例えば

LIST ALL PERMISSIONS OF alice;

他のロールから推移的に取得した権限を含め、aliceに付与されたすべての権限を表示します。

LIST ALL PERMISSIONS ON keyspace1.table1 OF bob;

他のロールから推移的に取得した権限を含め、keyspace1.table1に対してbobに付与されたすべての権限を表示します。これには、keyspace1.table1に適用できるリソース階層の上位にある権限も含まれます。たとえば、bobがkeyspace1に対してALTER権限を持っている場合、その権限はクエリ結果に含まれます。NORECURSIVEスイッチを追加すると、結果がbobまたはbobのロールのいずれかに直接付与された権限のみに制限されます。

LIST SELECT PERMISSIONS OF carlos;

carlosまたはcarlosのロールのいずれかに付与された権限を表示します。これは、任意のリソースに対するSELECT権限に限定されます。

ASF
ファウンデーション
イベント
ライセンス
謝辞
セキュリティ
プライバシー
スポンサーシップ

© 2009- Apache Software FoundationのApache License 2.0に基づいて提供されています。Apache、Apacheの羽根ロゴ、Apache Cassandra、Cassandra、およびCassandraロゴは、Apache Software Foundationの登録商標または商標です。