Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # GRANT Define permisos de acceso para un usuario o rol. Los permisos incluyen opciones de acceso, como poder leer datos en tablas y vistas, escribir datos, crear tablas y eliminarlas. Utilice este comando para otorgar permisos específicos a una tabla, base de datos, esquema, función, procedimiento, lenguaje o columna. Para revocar los permisos de un objeto de la base de datos, utilice el comando [REVOKE](r_REVOKE.md). Los permisos también incluyen las siguientes opciones de acceso al productor de recursos compartidos de datos: + Otorgar acceso a un recurso compartido de datos a los espacios de nombres y las cuentas del consumidor. + Otorgar permiso para modificar un recurso compartido de datos mediante la adición o eliminación de objetos del recurso compartido de datos. + Otorgar permiso para compartir un recurso compartido de datos mediante la adición o eliminación de espacios de nombres del consumidor del recurso compartido de datos. Las opciones de acceso para consumidores de recursos compartidos de datos son las siguientes: + Otorgar a los usuarios acceso total a las bases de datos creadas a partir de un recurso compartido de datos o a esquemas externos que apuntan a dichas bases de datos. + Otorgar a los usuarios permisos de nivel de objeto en las bases de datos creadas a partir de un recurso compartido de datos, tal como se hace con los objetos de bases de datos locales. Para conceder este nivel de permiso, debe utilizar la cláusula WITH PERMISSIONS al crear una base de datos a partir del recurso compartido de datos. Para obtener más información, consulte [CREATE DATABASE](r_CREATE_DATABASE.md). Para obtener más información sobre permisos de recursos compartidos de datos, consulte [Permisos que puede conceder a los recursos compartidos de datos](permissions-datashares.md). Los permisos también incluyen el siguiente catálogo de permisos federados de Amazon Redshift: + Concesión de permisos por tabla a usuarios y roles. + Concesión de permisos detallados por columna sobre tablas, vistas y vistas materializadas. + Concesión de permisos acotados a usuarios y roles. + Concesión de permisos por base de datos en el catálogo de permisos federados de Amazon Redshift. Para obtener más información acerca de la administración de permisos en el catálogo de permisos federados de Amazon Redshift, consulte [Administración del control de acceso en el catálogo de permisos federados de Amazon RedshiftConcesión / Revocación](federated-permissions-managing-access.md). Para obtener más información sobre las sintaxis de concesión o revocación compatibles con el catálogo de permisos federados de Amazon Redshift, consulte [Concesión/Revocación](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions-managing-access.html#federated-permissions-managing-access-grant-revoke). Los permisos también incluyen el privilegio CONNECT para los usuarios federados de AWS IAM Identity Center. Este privilegio permite a los administradores controlar el acceso de los usuarios mediante permisos granulares en cada grupo de trabajo o clúster de Amazon Redshift en los que estén habilitados los permisos federados de Amazon Redshift. El administrador de Amazon Redshift puede especificar qué usuarios o grupos de AWS IAM Identity Center federados tienen acceso para conectarse directamente al grupo de trabajo de Amazon Redshift, lo que proporciona un control detallado del acceso de los usuarios a cada grupo de trabajo o clúster de AWS IAM Identity Center. También puede conceder roles para administrar los permisos de base de datos y controlar lo que los usuarios pueden hacer en relación con los datos. Al definir roles y asignarlos a los usuarios, puede limitar las acciones que estos pueden realizar, como, por ejemplo, limitar a los usuarios solo a los comandos CREATE TABLE e INSERT. Para obtener más información sobre el comando CREATE ROLE, consulte [CREATE ROLE](r_CREATE_ROLE.md). Amazon Redshift dispone de algunos roles definidos por el sistema que también puede utilizar para conceder permisos específicos a sus usuarios. Para obtener más información, consulte [Roles definidos por el sistema de Amazon Redshift](r_roles-default.md). Solo puede usar permisos GRANT o REVOKE USAGE en un esquema externo de los usuarios de la base de datos y los grupos de usuarios que utilicen la sintaxis ON SCHEMA. Cuando use ON EXTERNAL SCHEMA con AWS Lake Formation, solo puede usar GRANT y REVOKE para conceder y revocar permisos a un rol de AWS Identity and Access Management (IAM). Para obtener una lista de los permisos, consulte la sintaxis. Para los procedimientos almacenados, el único permiso que puede concederse es EXECUTE. No se puede ejecutar GRANT (en un recurso externo) en un bloque de transacción (BEGIN … END). Para obtener más información acerca de las transacciones, consulte [Niveles de aislamiento en Amazon Redshift](c_serial_isolation.md). Para ver qué permisos se han concedido a los usuarios para una base de datos, utilice [HAS\$1DATABASE\$1PRIVILEGE](r_HAS_DATABASE_PRIVILEGE.md). Para ver qué permisos se han concedido a los usuarios para un esquema, utilice [HAS\$1SCHEMA\$1PRIVILEGE](r_HAS_SCHEMA_PRIVILEGE.md). Para ver qué permisos se han concedido a los usuarios para una tabla, utilice [HAS\$1TABLE\$1PRIVILEGE](r_HAS_TABLE_PRIVILEGE.md). ## Sintaxis ``` GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | REFERENCES | ALTER | TRUNCATE } [,...] | ALL [ PRIVILEGES ] } ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | TEMPORARY | TEMP | ALTER } [,...] | ALL [ PRIVILEGES ] } ON DATABASE db_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } ON SCHEMA schema_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { FUNCTION function_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL FUNCTIONS IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { PROCEDURE procedure_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL PROCEDURES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT USAGE ON LANGUAGE language_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } ON COPY JOB job_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } ON TEMPLATE [database_name.][schema_name.]template_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Concesión de permisos de nivel de columna para tablas A continuación, se muestra la sintaxis de los permisos de nivel de columna en tablas y vistas de Amazon Redshift. ``` GRANT { { SELECT | UPDATE } ( column_name [, ...] ) [, ...] | ALL [ PRIVILEGES ] ( column_name [,...] ) } ON { [ TABLE ] table_name [, ...] } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Concesión de permisos ASSUMEROLE A continuación, se muestra la sintaxis de los permisos ASSUMEROLE concedidos a usuarios y grupos con un rol especificado. Para empezar a utilizar el privilegio ASSUMEROLE, consulte [Notas de uso para conceder el permiso ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` GRANT ASSUMEROLE ON { 'iam_role' [, ...] | default | ALL } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] FOR { ALL | COPY | UNLOAD | EXTERNAL FUNCTION | CREATE MODEL } [, ...] ``` ### Concesión de permisos para la integración de Redshift Spectrum con Lake Formation A continuación, se muestra la sintaxis para la integración de Redshift Spectrum con Lake Formation. ``` GRANT { SELECT | ALL [ PRIVILEGES ] } ( column_list ) ON EXTERNAL TABLE schema_name.table_name TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] GRANT { { SELECT | ALTER | DROP | DELETE | INSERT } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL TABLE schema_name.table_name [, ...] TO { { IAM_ROLE iam_role } [, ...] | PUBLIC } [ WITH GRANT OPTION ] GRANT { { CREATE | ALTER | DROP } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL SCHEMA schema_name [, ...] TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] ``` ### Concesión de permisos de recurso compartido de datos **Permisos de recursos compartidos de datos del lado del productor** A continuación, se muestra la sintaxis para utilizar GRANT a fin de conceder permisos ALTER o SHARE a un usuario o rol. El usuario puede modificar el recurso compartido de datos con el permiso ALTER o conceder el uso a un consumidor con el permiso SHARE. ALTER y SHARE son los únicos permisos que se pueden conceder en recursos compartidos de datos a usuarios y a grupos de usuarios. ``` GRANT { ALTER | SHARE } ON DATASHARE datashare_name TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` A continuación, se muestra la sintaxis para utilizar GRANT en los permisos de uso de recurso compartido de datos en Amazon Redshift. Con el permiso USAGE se concede acceso a un recurso compartido de datos a un consumidor. No se puede conceder este permiso a usuarios o grupos de usuarios. Este permiso tampoco admite WITH GRANT OPTION para la instrucción GRANT. Solo los usuarios o los grupos de usuarios a los que se haya concedido el permiso SHARE con anterioridad para el recurso compartido de datos pueden ejecutar este tipo de instrucción GRANT. ``` GRANT USAGE ON DATASHARE datashare_name TO NAMESPACE 'namespaceGUID' | ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] ``` A continuación, se ofrece un ejemplo de cómo conceder el uso de un recurso compartido de datos a una cuenta de Lake Formation. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012' VIA DATA CATALOG; ``` **Permisos de recursos compartidos de datos del lado del consumidor** A continuación, se muestra la sintaxis para los permisos de uso compartido de datos GRANT en una base de datos específica o un esquema específico creados a partir de un datashare. Los demás permisos necesarios para que los consumidores accedan a una base de datos creada a partir de un recurso compartido de datos varían en función de si el comando CREATE DATABASE utilizado para crear la base de datos a partir del recurso compartido de datos ha utilizado o no la cláusula WITH PERMISSIONS. Para obtener más información acerca del comando CREATE DATABASE y la cláusula WITH PERMISSIONS, consulte [CREATE DATABASE](r_CREATE_DATABASE.md). **Bases de datos creadas sin usar la cláusula WITH PERMISSIONS** Al conceder USAGE a una base de datos creada a partir de un recurso compartido de datos sin la cláusula WITH PERMISSIONS, no es necesario conceder permisos por separado a los objetos de la base de datos compartida. Las entidades a las que se concede el uso en bases de datos creadas a partir de recursos compartidos de datos sin la cláusula WITH PERMISSIONS tienen acceso automáticamente a todos los objetos de la base de datos. **Bases de datos creadas con la cláusula WITH PERMISSIONS** Al conceder USAGE a una base de datos en la que se ha creado la base de datos compartida a partir de un recurso compartido de datos con la cláusula WITH PERMISSIONS, a las identidades del lado del consumidor se les deben seguir concediendo los permisos pertinentes para los objetos de la base de datos compartida para acceder a ellas, del mismo modo que se concederían permisos a los objetos de la base de datos local. Para conceder permisos a los objetos de una base de datos creada a partir de un recurso compartido de datos, utilice la sintaxis de tres partes `database_name.schema_name.object_name`. Para conceder permisos a los objetos en un esquema externo que apunte a un esquema compartido dentro de la base de datos compartida, utilice la sintaxis de dos partes `schema_name.object_name`. ``` GRANT USAGE ON { DATABASE shared_database_name [, ...] | SCHEMA shared_schema} TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Concesión de permisos acotados Los permisos limitados le permiten conceder permisos a un usuario o rol en todos los objetos de un tipo dentro de una base de datos o un esquema. Los usuarios y roles con permisos limitados tienen los permisos especificados en todos los objetos actuales y futuros de la base de datos o del esquema. Puede ver el alcance de los permisos limitados en el nivel de base de datos en [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Puede ver el alcance de los permisos limitados en el nivel de esquema en [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md). Para obtener más información sobre los permisos acotados, consulte [Permisos acotados](t_scoped-permissions.md). A continuación, se muestra la sintaxis para conceder permisos acotados a usuarios y roles. ``` GRANT { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } FOR SCHEMAS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | ALTER | TRUNCATE | REFERENCES } [, ...] } | ALL [PRIVILEGES] } } FOR TABLES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name} [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR FUNCTIONS IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR PROCEDURES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT USAGE FOR LANGUAGES IN {DATABASE db_name} TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { CREATE | ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } FOR COPY JOBS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } FOR TEMPLATES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] ``` Tenga en cuenta que los permisos limitados no distinguen entre los permisos de las funciones y los de los procedimientos. Por ejemplo, la siguiente instrucción concede a `bob` el permiso `EXECUTE` tanto para las funciones como para los procedimientos en el esquema `Sales_schema`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` ### Concesión de permisos de machine learning A continuación, se muestra la sintaxis para los permisos de modelos de machine learning en Amazon Redshift. ``` GRANT CREATE MODEL TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON MODEL model_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Concesión de permisos de rol La siguiente es la sintaxis para conceder roles en Amazon Redshift. ``` GRANT { ROLE role_name } [, ...] TO { { user_name [ WITH ADMIN OPTION ] } | ROLE role_name }[, ...] ``` A continuación, se muestra la sintaxis para conceder permisos de sistema a los roles en Amazon Redshift. Tenga en cuenta que solo puede conceder permisos a los roles, no a los usuarios. ``` GRANT { { CREATE USER | DROP USER | ALTER USER | CREATE SCHEMA | DROP SCHEMA | ALTER DEFAULT PRIVILEGES | ACCESS CATALOG | ACCESS SYSTEM TABLE CREATE TABLE | DROP TABLE | ALTER TABLE | CREATE OR REPLACE FUNCTION | CREATE OR REPLACE EXTERNAL FUNCTION | DROP FUNCTION | CREATE OR REPLACE PROCEDURE | DROP PROCEDURE | CREATE OR REPLACE VIEW | DROP VIEW | CREATE MODEL | DROP MODEL | CREATE DATASHARE | ALTER DATASHARE | DROP DATASHARE | CREATE LIBRARY | DROP LIBRARY | CREATE ROLE | DROP ROLE | TRUNCATE TABLE VACUUM | ANALYZE | CANCEL | IGNORE RLS | EXPLAIN RLS | EXPLAIN MASKING }[, ...] } | { ALL [ PRIVILEGES ] } TO ROLE role_name [, ...] ``` ### Concesión de permisos EXPLAIN para políticas de seguridad A continuación, se muestra la sintaxis para conceder permisos para explicar los filtros de la política de seguridad de una consulta en el plan EXPLAIN. Las posibles políticas de seguridad incluyen políticas de seguridad por fila y políticas de enmascaramiento de datos dinámico. ``` GRANT EXPLAIN { RLS | MASKING } TO ROLE rolename ``` Con la siguiente sintaxis, se puede conceder permisos para omitir las políticas de seguridad de la fila para una consulta. Esta sintaxis no se aplica a las políticas de enmascaramiento de datos dinámico. ``` GRANT IGNORE RLS TO ROLE rolename ``` Con la siguiente sintaxis, se pueden conceder permisos de tabla de búsqueda a la política de seguridad especificada. Las posibles políticas de seguridad incluyen políticas de seguridad por fila y políticas de enmascaramiento de datos dinámico. ``` GRANT SELECT ON [ TABLE ] table_name [, ...] TO { RLS | MASKING } POLICY policy_name [, ...] ``` ### Concesión de permisos de conexión A continuación, se muestra la sintaxis para conceder permisos a los usuarios (o grupos) federados de AWS IAM Identity Center para que se conecten a un grupo de trabajo o clúster: ``` GRANT CONNECT [ON WORKGROUP] TO [USER] : | ROLE : | PUBLIC; ``` ## Parameters SELECT Concede permiso para seleccionar datos de una tabla o vista mediante una instrucción SELECT. También se requiere el permiso SELECT para hacer referencia a los valores de columna existentes para las operaciones UPDATE o DELETE. INSERT Concede el permiso para cargar datos en una tabla mediante una instrucción INSERT o COPY. UPDATE Concede el privilegio para actualizar una columna de tabla mediante una instrucción UPDATE. Las operaciones UPDATE también requieren el permiso SELECT, ya que deben hacer referencia a las columnas de tabla para determinar cuáles son las filas que se deben actualizar o para calcular nuevos valores para las columnas. DELETE Concede el permiso para eliminar una fila de datos de una tabla. Las operaciones DELETE también requieren el permiso SELECT, ya que deben hacer referencia a las columnas de tabla para determinar cuáles son las filas que se deben eliminar. DROP Según el objeto de base de datos, concede los siguientes permisos al usuario o al rol: + En el caso de las tablas, DROP concede permiso para eliminar una tabla o una vista. Para obtener más información, consulte [DROP TABLE](r_DROP_TABLE.md). + En el caso de las bases de datos, DROP concede permiso para eliminar una base de datos. Para obtener más información, consulte [DROP DATABASE](r_DROP_DATABASE.md). + En el caso de los esquemas, DROP concede permiso para eliminar un esquema. Para obtener más información, consulte [DROP SCHEMA](r_DROP_SCHEMA.md). REFERENCES Concede el permiso para crear una restricción de clave externa. Es necesario conceder este permiso en la tabla a la que se hace referencia y en la tabla que hace la referencia; de lo contrario, el usuario no podrá crear la restricción. ALTER Según el objeto de base de datos, concede los siguientes permisos al usuario o al grupo de usuarios: + En el caso de las tablas, ALTER concede permiso para modificar una tabla o una vista. Para obtener más información, consulte [ALTER TABLE](r_ALTER_TABLE.md). + En el caso de las bases de datos, ALTER concede permiso para modificar una base de datos. Para obtener más información, consulte [ALTER DATABASE](r_ALTER_DATABASE.md). + En el caso de los esquemas, ALTER concede permiso para modificar un esquema. Para obtener más información, consulte [ALTER SCHEMA](r_ALTER_SCHEMA.md). + En el caso de las tablas externas, ALTER concede permiso para alterar una tabla en un AWS Glue Data Catalog que esté habilitado para Lake Formation. Este permiso solo se aplica cuando se utiliza Lake Formation. TRUNCATE Concede permiso para truncar una tabla. Sin este permiso, solo el propietario de una tabla o un superusuario pueden truncarla. Para obtener más información sobre el comando TRUNCATE, consulte [TRUNCATE](r_TRUNCATE.md). ALL [ PRIVILEGES ] Concede todos los permisos disponibles a la vez al usuario o al rol especificado. La palabra clave PRIVILEGES es opcional. GRANT ALL ON SCHEMA no concede permisos CREATE para esquemas externos. Puede conceder el permiso ALL a una tabla en un AWS Glue Data Catalog que está habilitado para Lake Formation. En este caso, los permisos individuales (como SELECT, ALTER, etc.) se registran en el catálogo de datos. Amazon Redshift no admite los permisos RULE y TRIGGER. Para obtener más información, consulte [Características no compatibles de PostgreSQL](c_unsupported-postgresql-features.md). ASSUMEROLE Concede permiso para ejecutar los comandos COPY, UNLOAD, EXTERNAL FUNCTION y CREATE MODEL a usuarios, roles o grupos con un rol especificado. El usuario, el rol o el grupo asume ese rol cuando se ejecuta el comando especificado. Para empezar a utilizar el permiso ASSUMEROLE, consulte [Notas de uso para conceder el permiso ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ON [ TABLE ] *table\$1name* Concede los permisos especificados en una tabla o vista. La palabra clave TABLE es opcional. Puede enumerar varias tablas y vistas en una instrucción. ON ALL TABLES IN SCHEMA *schema\$1name (nombre\$1de\$1esquema)* Concede los permisos especificados en todas las tablas y vistas en el esquema al que se hace referencia. ( *column\$1name* [,...] ) ON TABLE *table\$1name* Concede los permisos especificados a usuarios, grupos o PUBLIC en las columnas especificadas de la tabla o la vista de Amazon Redshift. ( *column\$1list* ) ON EXTERNAL TABLE *schema\$1name.table\$1name* Concede los permisos especificados a un rol de IAM en las columnas especificadas de la tabla de Lake Formation en el esquema al que se hace referencia. ON EXTERNAL TABLE *schema\$1name.table\$1name* Concede los permisos especificados a un rol de IAM en las tablas de Lake Formation especificadas en el esquema al que se hace referencia. ON EXTERNAL SCHEMA *schema\$1name* Concede los permisos especificados a un rol de IAM en el esquema al que se hace referencia. ON *iam\$1role* Concede los permisos especificados a un rol de IAM. TO *username* Indica el usuario que recibe los permisos. TO IAM\$1ROLE *iam\$1role* Indica el rol de IAM que recibe los permisos. WITH GRANT OPTION Indica que el usuario que recibe los permisos puede, a su vez, conceder los mismos permisos a otros usuarios. No se puede conceder WITH GRANT OPTION a un grupo o a PUBLIC. ROLE *role\$1name* Concede el permiso a un rol. GROUP *group\$1name* Concede los permisos para a un grupo de usuarios. Puede ser una lista separada por comas para especificar varios grupos de usuarios. PUBLIC Concede los permisos especificados a todos los usuarios, incluidos los creados posteriormente. PUBLIC representa un grupo que siempre incluye a todos los usuarios. Los permisos de un usuario individual constan de la suma de permisos concedidos a PUBLIC, los permisos concedidos a cualquier grupo al que pertenezca el usuario y los permisos concedidos al usuario de manera individual. La concesión de PUBLIC a una tabla externa de Lake Formation da lugar a la concesión del permiso al grupo *everyone* de Lake Formation. CONNECT [ON WORKGROUP] TO \$1 [USER] : \$1 ROLE : \$1 PUBLIC \$1 Otorga el permiso para conectarse a un grupo de trabajo o clúster a usuarios o grupos de AWS IAM Identity Center federados. El prefijo identifica al proveedor de identidad. Cuando se concede a PUBLIC, el permiso se aplica a todos los usuarios federados de AWS IAM Identity Center, incluidos los creados posteriormente. Este permiso solo se aplica cuando los permisos federados de Amazon Redshift están habilitados en el grupo de trabajo o el clúster. CREATE Según el objeto de base de datos, concede los siguientes permisos al usuario o al grupo de usuarios: + Para las bases de datos, CREATE permite que los usuarios creen esquemas dentro de la base de datos. + Para los esquemas, CREATE permite que los usuarios creen objetos dentro de un esquema. Para cambiar el nombre de un objeto, el usuario debe tener el permiso CREATE y ser propietario del objeto cuyo nombre va a cambiarse. + CREATE ON SCHEMA no se admite para esquemas externos de Amazon Redshift Spectrum. Para conceder permisos para usar tablas externas en un esquema externo, conceda el privilegio USAGE ON SCHEMA a los usuarios que necesitan tener acceso. Solo el propietario de un esquema externo o un superusuario pueden crear tablas externas en el esquema externo. Para transferir la propiedad de un esquema externo, use [ALTER SCHEMA](r_ALTER_SCHEMA.md) para cambiar el propietario. TEMPORARY \$1 TEMP Concede el permiso para crear tablas temporales en la base de datos especificada. Para ejecutar consultas de Amazon Redshift Spectrum, el usuario de la base de datos debe tener permiso para crear tablas temporales en la base de datos. Por defecto, los usuarios reciben permisos para crear tablas temporales con su membresía automática en el grupo PUBLIC. Para quitar el permiso para que cualquier usuario pueda crear tablas temporales, revoque el permiso TEMP del grupo PUBLIC. A continuación, conceda explícitamente el permiso para crear tablas temporales a usuarios o grupos de usuarios específicos. ON DATABASE *db\$1name* Concede los permisos especificados en una base de datos. USAGE Concede el permiso USAGE en un esquema específico, lo que permite que los usuarios obtengan acceso a los objetos de ese esquema. Las acciones específicas en estos objetos deben concederse por separado (por ejemplo, permisos SELECT o UPDATE en las tablas) para los esquemas locales de Amazon Redshift. De forma predeterminada, todos los usuarios tienen permisos CREATE y USAGE en el esquema PUBLIC. Al conceder USAGE a esquemas externos mediante la sintaxis ON SCHEMA, no es necesario conceder acciones por separado a los objetos del esquema externo. Los permisos de catálogo correspondientes controlan los permisos detallados de los objetos de esquema externos. ON SCHEMA *schema\$1name* Concede los permisos especificados en un esquema. GRANT CREATE ON SCHEMA y el permiso CREATE en GRANT ALL ON SCHEMA no se admiten para esquemas externos de Amazon Redshift Spectrum. Para conceder permisos para usar tablas externas en un esquema externo, conceda el privilegio USAGE ON SCHEMA a los usuarios que necesitan tener acceso. Solo el propietario de un esquema externo o un superusuario pueden crear tablas externas en el esquema externo. Para transferir la propiedad de un esquema externo, use [ALTER SCHEMA](r_ALTER_SCHEMA.md) para cambiar el propietario. EXECUTE ON ALL FUNCTIONS IN SCHEMA *schema\$1name* Concede los permisos especificados en todas las funciones en el esquema al que se hace referencia. Amazon Redshift no admite las instrucciones GRANT ni REVOKE para las entradas integradas de pg\$1proc definidas en el espacio de nombres pg\$1catalog. EXECUTE ON PROCEDURE *procedure\$1name* Concede el permiso EXECUTE en un procedimiento almacenado específico. Debido a que los nombres de procedimientos almacenados no se pueden sobrecargar, debe incluir la lista de argumentos para el procedimiento. Para obtener más información, consulte [Nomenclatura de los procedimientos almacenados](stored-procedure-naming.md). EXECUTE ON ALL PROCEDURES IN SCHEMA *schema\$1name* Concede los permisos especificados en todos los procedimientos almacenados en el esquema al que se hace referencia. USAGE ON LANGUAGE *language\$1name* Concede el permiso USAGE en un lenguaje. A partir del 1 de noviembre de 2025, Amazon Redshift dejará de admitir la creación de nuevas UDF de Python. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. A partir del 1 de julio de 2026, Amazon Redshift dejará de admitir las UDF de Python. Le recomendamos que migre las UDF de Python existentes a UDF de Lambda antes del 1 de noviembre de 2025. Para obtener información sobre cómo crear y utilizar las UDF de Lambda, consulte [UDF de Lambda escalares](udf-creating-a-lambda-sql-udf.md). Para obtener información sobre cómo convertir las UDF de Python existentes en UDF de Lambda, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Se requiere el permiso USAGE ON LANGUAGE para crear funciones definidas por el usuario (UDF) mediante la ejecución del comando [CREATE FUNCTION](r_CREATE_FUNCTION.md). Para obtener más información, consulte [Seguridad y permisos de UDF](udf-security-and-privileges.md). Se requiere el permiso USAGE ON LANGUAGE para crear procedimientos almacenados mediante la ejecución del comando [CREATE PROCEDURE](r_CREATE_PROCEDURE.md). Para obtener más información, consulte [Seguridad y privilegios para procedimientos almacenados](stored-procedure-security-and-privileges.md). Para las UDF de Python, use `plpythonu`. Para las UDF de SQL, use `sql`. Para procedimientos almacenados, utilice `plpgsql`. ON COPY JOB *job\$1name* Concede los permisos especificados en un trabajo de copia. FOR \$1 ALL \$1 COPY \$1 UNLOAD \$1 EXTERNAL FUNCTION \$1 CREATE MODEL \$1 [, ...] Especifica el comando SQL para el que se concede el permiso. Puede especificar ALL para conceder el permiso en las instrucciones COPY, UNLOAD, EXTERNAL FUNCTION y CREATE MODEL. Esta cláusula se aplica solo a la concesión del permiso ASSUMEROLE. ALTER Concede el permiso ALTER a los usuarios para agregar o quitar objetos de un recurso compartido de datos o para establecer la propiedad PUBLICACCESSIBLE. Para obtener más información, consulte [ALTER DATASHARE](r_ALTER_DATASHARE.md). SHARE Concede permisos a usuarios y grupos de usuarios para agregar consumidores de datos a un recurso compartido de datos. Este permiso es necesario para permitir que un consumidor determinado (cuenta o espacio de nombres) acceda al recurso compartido de datos desde sus clústeres. El consumidor puede ser la misma cuenta de AWS o una diferente, con el mismo espacio de nombres del clúster o con uno diferente, como lo especifica un identificador global único (GUID). ON DATASHARE *datashare\$1name* Concede los permisos especificados en el recurso compartido de datos al que se hace referencia. Para obtener información sobre el grado de detalle del control de acceso de los consumidores, consulte [Uso compartido de datos en niveles diferentes en Amazon Redshift](datashare-overview.md#granularity). USAGE Cuando USAGE se concede a una cuenta consumidora o un espacio de nombres de la misma cuenta, estos pueden acceder al datashare y a los objetos del datashare para lectura solamente. TO NAMESPACE 'clusternamespace GUID' Indica un espacio de nombres en la misma cuenta donde los consumidores pueden recibir los permisos especificados para el recurso compartido de datos. Los espacios de nombres utilizan un GUID alfanumérico de 128 bits. TO ACCOUNT 'número\$1de\$1cuenta' [ VIA DATA CATALOG ] Indica el número de otra cuenta cuyos consumidores pueden recibir los permisos especificados para el recurso compartido de datos. Si especifica “VIA DATA CATALOG”, se indica que concede el uso del recurso compartido de datos a una cuenta de Lake Formation. La omisión de este parámetro significa que concede el uso a una cuenta que es propietaria del clúster. ON DATABASE *shared\$1database\$1name> [, ...]* Concede los permisos de uso especificados en la base de datos concreta que se crea en el recurso compartido de datos indicado. ON SCHEMA* shared\$1schema* Concede los permisos especificados en el esquema concreto que se crea en el recurso compartido de datos indicado. FOR \$1 SCHEMAS \$1 TABLES \$1 FUNCTIONS \$1 PROCEDURES \$1 LANGUAGES \$1 COPY JOBS\$1 IN Especifica los objetos de la base de datos a los que se va a conceder permiso. Los parámetros después de IN definen el alcance del permiso concedido. CREATE MODEL Concede el permiso CREATE MODEL a usuarios o grupos de usuarios específicos. ON MODEL *model\$1name* Concede el permiso EXECUTE en un modelo específico. ACCESS CATALOG Otorga el permiso para ver los metadatos relevantes de los objetos a los que tiene acceso el rol. \$1 role \$1 [, …] Rol que se debe conceder a otro rol, usuario o PUBLIC. PUBLIC representa un grupo que siempre incluye a todos los usuarios. Los permisos de un usuario individual constan de la suma de permisos concedidos a PUBLIC, los permisos concedidos a cualquier grupo al que pertenezca el usuario y los permisos concedidos al usuario de manera individual. TO \$1 \$1 *user\$1name* [ WITH ADMIN OPTION ] \$1 \$1 role \$1[, …] Concede el rol especificado a un usuario especificado con WITH ADMIN OPTION, otro rol o PUBLIC. La cláusula WITH ADMIN OPTION proporciona las opciones de administración de todos los roles concedidos a todos los beneficiarios de las concesiones. EXPLAIN \$1 RLS \$1 MASKING \$1 TO ROLE *rolename* Concede a un rol el permiso de explicar los filtros de política de seguridad de una consulta en el plan EXPLAIN. Concesión de permisos de RLS para explicar filtros de políticas de seguridad por fila. MASKING concede permiso para explicar los filtros de la política de enmascaramiento de datos dinámico. IGNORE RLS TO ROLE *nombre\$1de\$1rol* Concede a un rol el permiso de eludir las políticas de seguridad de nivel de fila para una consulta. TO \$1 RLS \$1 MASKING \$1 POLICY *policy\$1name* Indica la política de seguridad que recibe los permisos. TO RLS POLICY indica una política de seguridad por fila. TO MASKING POLICY indica una política de enmascaramiento de datos dinámico. ## Notas de uso Para obtener más información acerca de las notas de uso de GRANT, consulte [Notas de uso](r_GRANT-usage-notes.md). ## Ejemplos Para ver ejemplos de cómo utilizar GRANT, consulte [Ejemplos](r_GRANT-examples.md). # Notas de uso Para conceder privilegios en un objeto, debe cumplir con uno de los siguientes criterios: + Ser el propietario del objeto. + Ser un superusuario. + Tener un privilegio concedido para ese objeto y privilegio. Por ejemplo, el siguiente comando permite al usuario HR realizar comandos SELECT en la tabla de empleados y conceder y revocar el mismo privilegio para otros usuarios: ``` grant select on table employees to HR with grant option; ``` HR no puede conceder privilegios para ninguna operación que no sea SELECT o en ninguna tabla que no sea la de empleados. Como otro ejemplo, el siguiente comando permite al usuario HR ejecutar comandos ALTER en la tabla de empleados y conceder y revocar el mismo privilegio para otros usuarios. ``` grant ALTER on table employees to HR with grant option; ``` HR no puede conceder privilegios para ninguna otra operación que no sea ALTER ni sobre ninguna otra tabla que no sea employees. Tener privilegios concedidos de una vista no implica tener privilegios en las tablas subyacentes. De manera similar, tener privilegios concedidos de un esquema no implica tener privilegios en las tablas del esquema. En su lugar, debe conceder acceso a las tablas subyacentes de manera explícita. Para otorgar privilegios a una tabla AWS Lake Formation, el rol IAM asociado con el esquema externo de la tabla debe tener permiso para otorgar privilegios en la tabla externa. El siguiente ejemplo crea un esquema externo con un rol IAM asociado `myGrantor`. El rol IAM `myGrantor` tiene el permiso para otorgar permisos a otros. El comando GRANT utiliza los permisos del rol `myGrantor` IAM que está asociado al esquema externo para otorgar permisos al rol IAM `myGrantee`. ``` create external schema mySchema from data catalog database 'spectrum_db' iam_role 'arn:aws:iam::123456789012:role/myGrantor' create external database if not exists; ``` ``` grant select on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Si concede privilegios GRANT ALL a un rol de IAM, los privilegios individuales se conceden en el catálogo de datos relacionado y habilitado para Lake Formation. Por ejemplo, el siguiente permiso GRANT ALL da lugar a los privilegios individuales concedidos (SELECT, ALTER, DROP, DELETE e INSERT) que se muestran en la consola de Lake Formation. ``` grant all on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Los superusuarios pueden obtener acceso a todos los objetos independientemente de los comandos GRANT y REVOKE que establecen privilegios de objeto. ## Notas de uso para el control de acceso de nivel de columna Las siguientes notas de uso se aplican a los privilegios del nivel de la columna en tablas y vistas de Amazon Redshift. Estas notas describen tablas; las mismas notas se aplican a las vistas a menos que anotemos explícitamente una excepción. + En una tabla de Amazon Redshift, solo se pueden conceder los privilegios SELECT y UPDATE en el nivel de la columna. En una vista de Amazon Redshift, solo se puede conceder el privilegio SELECT en el nivel de la columna. + La palabra clave ALL es sinónimo de una combinación de los privilegios SELECT y UPDATE cuando se utiliza en el contexto de GRANT en el nivel de columna en una tabla. + Si no tiene el privilegio SELECT en todas las columnas de una tabla, al realizar una operación SELECT \$1 solo se devolverán las columnas a las que tiene acceso. Cuando se utiliza una vista, la operación SELECT \$1 intenta acceder a todas las columnas de la vista. Si no tiene permiso para acceder a todas las columnas, estas consultas producen un error de permiso denegado. + SELECT \$1 no se expande solo a columnas accesibles en los siguientes casos: + No puede crear una vista normal solo con columnas accesibles mediante SELECT \$1. + No puede crear una vista materializada solo con columnas accesibles mediante SELECT \$1. + Si tiene privilegios SELECT o UPDATE en una tabla o vista y agrega una columna, seguirá teniendo los mismos privilegios en la tabla o vista y, por tanto, en todas sus columnas. + Sólo el propietario de una tabla o un superusuario pueden conceder privilegios de nivel de columna. + No se admite la cláusula WITH GRANT OPTION para privilegios de nivel de columna. + No puede mantener el mismo privilegio tanto en el nivel de tabla como en el nivel de columna. Por ejemplo, el usuario `data_scientist` no puede tener tanto el privilegio SELECT en la tabla `employee` como el privilegio SELECT en la columna `employee.department`. Tenga en cuenta los siguientes resultados al conceder el mismo privilegio a una tabla y a una columna dentro de la tabla: + Si un usuario tiene un privilegio de nivel de tabla en una tabla, conceder el mismo privilegio en el nivel de columna no tiene ningún efecto. + Si un usuario tiene un privilegio de nivel de tabla en una tabla, al revocar el mismo privilegio para una o varias columnas de la tabla se devuelve un error. En su lugar, revoque el privilegio en el nivel de tabla. + Si un usuario tiene un privilegio de nivel de columna, conceder el mismo privilegio en el nivel de tabla devuelve un error. + Si un usuario tiene un privilegio de nivel de columna, al revocar el mismo privilegio en el nivel de tabla se revocarán los privilegios de columna y tabla para todas las columnas de la tabla. + No se pueden conceder privilegios de nivel de columna en vistas de enlace en tiempo de ejecución. + Debe tener el privilegio SELECT de nivel de tabla en las tablas base para crear una vista materializada. Incluso si tiene privilegios de nivel de columna en columnas específicas, no puede crear una vista materializada solo en esas columnas. No obstante, puede conceder el privilegio SELECT a las columnas de una vista materializada, similar a las vistas normales. + Para buscar concesiones de privilegios de nivel de columna, utilice la vista [PG\$1ATTRIBUTE\$1INFO](r_PG_ATTRIBUTE_INFO.md) . ## Notas de uso para conceder el permiso ASSUMEROLE Las siguientes notas de uso se aplican cuando se concede el permiso ASSUMEROLE en Amazon Redshift. El permiso ASSUMEROLE se utiliza para controlar los permisos de acceso de rol de IAM para usuarios, roles y grupos de base de datos en comandos como COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL. Después de conceder el permiso ASSUMEROLE a un usuario, un rol o un grupo para un rol de IAM, el usuario, el rol o el grupo puede asumir ese rol cuando se ejecute el comando. El permiso ASSUMEROLE permite conceder acceso a los comandos adecuados según sea necesario. Solo un superusuario de base de datos puede conceder o revocar el permiso ASSUMEROLE para usuarios, roles y grupos. Un superusuario siempre retiene el permiso ASSUMEROLE. Para habilitar el uso del permiso ASSUMEROLE por parte de usuarios, roles y grupos, un superusuario realiza las dos acciones siguientes: + Ejecuta una vez la siguiente instrucción en el clúster: ``` revoke assumerole on all from public for all; ``` + Concede el permiso ASSUMEROLE a usuarios, roles y grupos para los comandos adecuados. Puede especificar el encadenamiento de roles en la cláusula ON cuando concede el permiso ASSUMEROLE. Utiliza comas para separar los roles en una cadena de roles; por ejemplo, `Role1,Role2,Role3`. Si se especificó el encadenamiento de roles durante la concesión del permiso ASSUMEROLE, deberá especificar la cadena de roles cuando realice operaciones concedidas por el permiso ASSUMEROLE. No se pueden especificar roles individuales en la cadena de roles cuando se realizan operaciones concedidas por el permiso ASSUMEROLE. Por ejemplo, si a un usuario, un rol o un grupo se le concede la cadena de roles `Role1,Role2,Role3`, no se puede especificar solo `Role1` para realizar operaciones. Si un usuario intenta realizar una operación COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL, y no se le ha concedido el permiso ASSUMEROLE, aparecerá un mensaje similar al siguiente. ``` ERROR: User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY ``` Para enumerar los usuarios a los que se les concedió acceso a roles de IAM y comandos a través del permiso ASSUMEROLE, consulte [HAS\$1ASSUMEROLE\$1PRIVILEGE](r_HAS_ASSUMEROLE_PRIVILEGE.md). Para enumerar los roles de IAM y los permisos de comando que se han concedido a un usuario que usted especifica, consulte [PG\$1GET\$1IAM\$1ROLE\$1BY\$1USER](PG_GET_IAM_ROLE_BY_USER.md). Para enumerar los usuarios, los roles y los grupos a los que se les concedió acceso a un rol de IAM que usted especificó, consulte [PG\$1GET\$1GRANTEE\$1BY\$1IAM\$1ROLE](PG_GET_GRANTEE_BY_IAMROLE.md). ## Notas de uso para conceder permisos de machine learning No puede conceder ni revocar directamente permisos relacionados con una función de ML. Una función de ML pertenece a un modelo de ML y los permisos se controlan mediante el modelo. En su lugar, puede conceder permisos relacionados con el modelo de ML. En el siguiente ejemplo, se muestra cómo conceder permisos a todos los usuarios para ejecutar la función de ML asociada al modelo `customer_churn`. ``` GRANT EXECUTE ON MODEL customer_churn TO PUBLIC; ``` También puede conceder todos los permisos a un usuario para el modelo de ML `customer_churn`. ``` GRANT ALL on MODEL customer_churn TO ml_user; ``` Se producirá un error en la concesión del permiso `EXECUTE` relacionado con una función de ML si existe una función de ML en el esquema, aunque dicha función de ML ya disponga del permiso `EXECUTE` mediante `GRANT EXECUTE ON MODEL`. Recomendamos utilizar un esquema independiente cuando utilice el comando `CREATE MODEL` para mantener las funciones de ML en un esquema independiente por sí mismas. En el siguiente ejemplo, se muestra cómo hacerlo. ``` CREATE MODEL ml_schema.customer_churn FROM customer_data TARGET churn FUNCTION ml_schema.customer_churn_prediction IAM_ROLE default SETTINGS ( S3_BUCKET 'amzn-s3-demo-bucket' ); ``` # Ejemplos En el siguiente ejemplo, se le concede el privilegio SELECT en la tabla SALES al usuario `fred`. ``` grant select on table sales to fred; ``` En el siguiente ejemplo, se le concede el privilegio SELECT en todas las tablas del esquema QA\$1TICKIT al usuario `fred`. ``` grant select on all tables in schema qa_tickit to fred; ``` En el siguiente ejemplo, se le conceden todos los privilegios del esquema en el esquema QA\$1TICKIT al grupo de usuarios QA\$1USERS. Los privilegios de esquema son CREATE y USAGE. USAGE concede a los usuarios acceso a los objetos del esquema, pero no les concede privilegios (como INSERT o SELECT) sobre esos objetos. Otorga privilegios en cada objeto por separado. ``` create group qa_users; grant all on schema qa_tickit to group qa_users; ``` En el siguiente ejemplo, se le conceden todos los privilegios de la tabla SALES en el esquema QA\$1TICKIT a todos los usuarios del grupo QA\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users; ``` En el siguiente ejemplo, se conceden todos los privilegios en la tabla SALES del esquema QA\$1TICKIT a todos los usuarios de los grupos QA\$1USERS y RO\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users, group ro_users; ``` En el siguiente ejemplo, se concede el privilegio DROP en la tabla SALES del esquema QA\$1TICKIT a todos los usuarios del grupo QA\$1USERS. ``` grant drop on table qa_tickit.sales to group qa_users;> ``` En la siguiente secuencia de comandos se muestra que obtener acceso a un esquema no concede privilegios en una tabla del esquema. ``` create user schema_user in group qa_users password 'Abcd1234'; create schema qa_tickit; create table qa_tickit.test (col1 int); grant all on schema qa_tickit to schema_user; set session authorization schema_user; select current_user; current_user -------------- schema_user (1 row) select count(*) from qa_tickit.test; ERROR: permission denied for relation test [SQL State=42501] set session authorization dw_user; grant select on table qa_tickit.test to schema_user; set session authorization schema_user; select count(*) from qa_tickit.test; count ------- 0 (1 row) ``` En la siguiente secuencia de comandos se muestra que obtener acceso a una vista no implica el acceso a sus tablas subyacentes. El usuario denominado VIEW\$1USER no puede seleccionar desde la tabla DATE aunque haya recibido todos los privilegios en VIEW\$1DATE. ``` create user view_user password 'Abcd1234'; create view view_date as select * from date; grant all on view_date to view_user; set session authorization view_user; select current_user; current_user -------------- view_user (1 row) select count(*) from view_date; count ------- 365 (1 row) select count(*) from date; ERROR: permission denied for relation date ``` En el siguiente ejemplo, se concede el privilegio SELECT en las columnas `cust_name` y `cust_phone` de la tabla `cust_profile` al usuario `user1`. ``` grant select(cust_name, cust_phone) on cust_profile to user1; ``` En el siguiente ejemplo, se concede el privilegio SELECT en las columnas `cust_name` y `cust_phone` y el privilegio UPDATE en la columna `cust_contact_preference` de la tabla `cust_profile` al grupo `sales_group`. ``` grant select(cust_name, cust_phone), update(cust_contact_preference) on cust_profile to group sales_group; ``` En el siguiente ejemplo, se muestra el uso de la palabra clave ALL para otorgar privilegios SELECT y UPDATE en tres columnas de la tabla `cust_profile` al grupo `sales_admin`. ``` grant ALL(cust_name, cust_phone,cust_contact_preference) on cust_profile to group sales_admin; ``` En el siguiente ejemplo, se concede el privilegio SELECT en la columna `cust_name` de la vista `cust_profile_vw` al usuario `user2`. ``` grant select(cust_name) on cust_profile_vw to user2; ``` ## Ejemplos de concesión de acceso a recursos compartidos de datos En los siguientes ejemplos, se muestran permisos de uso compartido de datos GRANT en una base de datos o un esquema específicos creados a partir de un datashare. En el siguiente ejemplo, un administrador del lado del productor concede el permiso USAGE del recurso compartido de datos `salesshare` al espacio de nombres especificado. ``` GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` En el siguiente ejemplo, un administrador del lado del consumidor concede el permiso USAGE en `sales_db` a `Bob`. ``` GRANT USAGE ON DATABASE sales_db TO Bob; ``` En el siguiente ejemplo, un administrador del lado del consumidor concede el permiso GRANT USAGE en el esquema `sales_schema` al rol `Analyst_role`. `sales_schema` es un esquema externo que apunta a sales\$1db. ``` GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` En este punto, `Bob` y `Analyst_role` pueden acceder a todos los objetos de la base de datos en `sales_schema` y `sales_db`. El siguiente ejemplo muestra la concesión de permisos adicionales en el nivel de objeto para los objetos de una base de datos compartida. Estos permisos adicionales solo son necesarios si el comando CREATE DATABASE que se ha utilizado para crear la base de datos compartida ha utilizado la cláusula WITH PERMISSIONS. Si el comando CREATE DATABASE no ha utilizado WITH PERMISSIONS, al conceder USAGE en la base de datos compartida se otorga acceso total a todos los objetos de esa base de datos. ``` GRANT SELECT ON sales_db.sales_schema.tickit_sales_redshift to Bob; ``` ## Ejemplos de concesión de permisos acotados El siguiente ejemplo concede el uso de todos los esquemas actuales y futuros de la base de datos `Sales_db` al rol `Sales`. ``` GRANT USAGE FOR SCHEMAS IN DATABASE Sales_db TO ROLE Sales; ``` El siguiente ejemplo otorga el permiso SELECT para todas las tablas actuales y futuras de la base de datos `Sales_db` al usuario `alice` y también otorga a `alice` el permiso para conceder permisos acotados en las tablas `Sales_db` a otros usuarios. ``` GRANT SELECT FOR TABLES IN DATABASE Sales_db TO alice WITH GRANT OPTION; ``` En el siguiente ejemplo, se concede el permiso EXECUTE para las funciones del esquema `Sales_schema` al usuario `bob`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` En el siguiente ejemplo se conceden todos los permisos para todas las tablas del esquema `ShareSchema` de la base de datos `ShareDb` al rol `Sales`. Al especificar el esquema, puede indicar la base de datos del esquema mediante el formato de dos partes `database.schema`. ``` GRANT ALL FOR TABLES IN SCHEMA ShareDb.ShareSchema TO ROLE Sales; ``` El siguiente ejemplo es el mismo que el anterior. Puede especificar la base de datos mediante la palabra clave `DATABASE` en lugar de utilizar un formato de dos partes. ``` GRANT ALL FOR TABLES IN SCHEMA ShareSchema DATABASE ShareDb TO ROLE Sales; ``` ## Ejemplos de concesión del privilegio ASSUMEROLE A continuación, se muestran ejemplos de concesión del privilegio ASSUMEROLE. En el siguiente ejemplo, se muestra la instrucción REVOKE que un superusuario ejecuta una vez en el clúster con objeto de habilitar el uso del privilegio ASSUMEROLE para usuarios y grupos. Luego, el superusuario concede el privilegio ASSUMEROLE a los usuarios y los grupos para los comandos adecuados. Para obtener información sobre cómo habilitar el uso del privilegio ASSUMEROLE para usuarios y grupos, consulte [Notas de uso para conceder el permiso ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` revoke assumerole on all from public for all; ``` En el siguiente ejemplo, se concede el privilegio ASSUMEROLE al usuario `reg_user1` para el rol de IAM `Redshift-S3-Read` con objeto de realizar operaciones COPY. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-S3-Read' to reg_user1 for copy; ``` En el siguiente ejemplo, se concede el privilegio ASSUMEROLE al usuario `reg_user1` para la cadena de roles de IAM `RoleA`, `RoleB` con objeto de realizar operaciones UNLOAD. ``` grant assumerole on 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB' to reg_user1 for unload; ``` A continuación, se muestra un ejemplo del comando UNLOAD a través de la cadena de roles de IAM `RoleA`, `RoleB`. ``` unload ('select * from venue limit 10') to 's3://companyb/redshift/venue_pipe_' iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB'; ``` En el siguiente ejemplo, se concede el privilegio ASSUMEROLE al usuario `reg_user1` para el rol de IAM `Redshift-Exfunc` con objeto de crear funciones externas. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-Exfunc' to reg_user1 for external function; ``` En el siguiente ejemplo, se concede el privilegio ASSUMEROLE al usuario `reg_user1` para el rol de IAM `Redshift-model` con objeto de crear modelos de machine learning. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-ML' to reg_user1 for create model; ``` ## Ejemplos de concesión de los privilegios ROLE El siguiente ejemplo concede sample\$1role1 a user1. ``` CREATE ROLE sample_role1; GRANT ROLE sample_role1 TO user1; ``` El siguiente ejemplo concede sample\$1role1 a user1 con WITH ADMIN OPTION, establece la sesión actual para user1, y user1 concede sample\$1role1 a user2. ``` GRANT ROLE sample_role1 TO user1 WITH ADMIN OPTION; SET SESSION AUTHORIZATION user1; GRANT ROLE sample_role1 TO user2; ``` El siguiente ejemplo concede sample\$1role1 a sample\$1role2. ``` GRANT ROLE sample_role1 TO ROLE sample_role2; ``` El siguiente ejemplo concede sample\$1role2 a sample\$1role3 y sample\$1role4. Luego, intenta conceder sample\$1role3 a sample\$1role1. ``` GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; ERROR: cannot grant this role, a circular dependency was detected between these roles ``` El siguiente ejemplo concede los privilegios del sistema CREATE USER a sample\$1role1. ``` GRANT CREATE USER TO ROLE sample_role1; ``` El siguiente ejemplo concede el rol definido por el sistema `sys:dba` a user1. ``` GRANT ROLE sys:dba TO user1; ``` El siguiente ejemplo intenta conceder sample\$1role3 en una dependencia circular a sample\$1role2. ``` CREATE ROLE sample_role3; GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; -- fail ERROR: cannot grant this role, a circular dependency was detected between these roles ```