Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Databricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
- Duración
- 17 min aprox.
- Objetivo
- Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
OpenSharing (antes Delta Sharing) y Federation
Comparte o consulta datos externos con el mínimo movimiento y un perímetro gobernado.
- Comparar Databricks-to-Databricks y Databricks-to-Open
- Configurar federation con pushdown
- Elegir compartir, federar o ingerir
03OperaciónDatabricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
+
Databricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
El proveedor conserva el control y puede revocar el recipient o retirar activos. Registra owner, propósito, región, base legal, clasificación, protocolo y método de autenticación. Audita acciones de shares/recipients y accesos según las system tables disponibles. Si usas bearer credentials, almacénalas como secretos, rota con solapamiento y destruye copias antiguas.
Row filters/masks y ABAC tienen limitaciones específicas al compartir; no presupongas que una política aplicada a la fuente se reproduce igual en el receptor. Prueba el share con una identidad real del recipient. Modela egress cloud y foreign compute en el coste, especialmente para vistas, materialized views, streaming tables o datos federados.
Modelo mental
Sharing cruza una frontera organizativa aunque los datos permanezcan en almacenamiento del proveedor. Cada consulta puede generar transferencia, credenciales temporales y eventos de acceso; por eso la evaluación abarca residencia, egress, identidad, retención y compatibilidad, no sólo un GRANT. Provider y recipient tienen responsabilidades distintas: el primero decide qué expone y monitorea solicitudes; el segundo gobierna quién puede leer el catálogo recibido y qué copias deriva. Una política ABAC del proveedor puede tener limitaciones o no gobernar el lado receptor como se imagina; el consumidor necesita sus propios controles. Bearer tokens se rotan y distribuyen con cuidado, OIDC se prefiere cuando está disponible, y todo onboarding incluye una prueba real de revocación.
Transferencia de datos desde la región o proveedor de almacenamiento hacia otra red, región, nube o consumidor externo.
Puede introducir coste, latencia y restricciones de residencia aunque OpenSharing evite una copia administrada previa.Credencial de alcance y duración reducidos generada para que un cliente lea únicamente datos autorizados de un share.
Limita exposición frente a claves permanentes, pero su generación y uso todavía requieren auditoría y controles.División de obligaciones donde provider gobierna publicación y recipient gobierna acceso y derivados dentro de su organización.
Evita asumir que una policy del origen protege automáticamente copias, usuarios o retención en el consumidor.SHOW SHARES;
SHOW RECIPIENTS;
SHOW ALL IN SHARE retail_partner;
-- Conserva la salida con owner, propósito y fecha de revisión
-- en una tabla de control gobernada, no en una hoja personal.Complementa el inventario con audit logs y el contrato del recipient; `SHOW` por sí solo no describe la base legal ni el coste.
Puntos clave
- Prueba la experiencia y restricciones desde el lado receptor.
- Incluye egress, compute y fuente remota en FinOps del share.
- Ensaya rotación y revocación antes del incidente.
Evita
- Suponer que una mask de la tabla base siempre se conserva igual en OpenSharing.
- Crear recipients sin owner o fecha de revisión y acumular acceso huérfano.
Recuerdo activo