Inbound Private Link ahora es compatible con Genie One a nivel de cuenta, la consola de cuenta y URL personalizadas

Las empresas que adoptan Databricks para sus datos más confidenciales suelen confiar en Inbound Private Link para mantener el tráfico de usuario a Databricks fuera de la internet pública, enrutándolo de forma privada a través de su propia red en la nube. A medida que los clientes escalan a múltiples espacios de trabajo, varias regiones y productos a nivel de cuenta como Genie One, hemos ampliado las capacidades de Inbound Private Link para adaptarnos a sus necesidades.

Novedades en Inbound Private Link

Inbound Private Link ahora admite recursos a nivel de cuenta, incluidos Genie One a nivel de cuenta, la consola de cuenta, el Governance Hub y las API a nivel de cuenta. Los clientes pueden colocar Genie One a nivel de cuenta detrás de Inbound Private Link con las mismas garantías de red que ya aplican en cualquier otro lugar.

Inbound Private Link ahora admite URL personalizadas y URL estables de recuperación ante desastres administrada. Inbound Private Link ahora funciona de extremo a extremo con URL personalizadas como acme.databricks.com. Esto se extiende a las URL estables de recuperación ante desastres administrada (por ejemplo, acme.databricks.com/?c=stable-ws-id).

Un único endpoint, cualquier región, para cada recurso de UI + API. Ahora, un único endpoint de acceso general compartido en cualquier región puede dar servicio a todas las UI y API a nivel de cuenta y de espacio de trabajo. Los clientes ya no necesitan crear un endpoint por región o espacio de trabajo. Los equipos con requisitos estrictos de aislamiento de red aún pueden usar múltiples endpoints; pero esos endpoints ya no están limitados a dar servicio a recursos en la misma región. Esto reduce el esfuerzo manual y el costo necesarios para mantener muchos endpoints. Nota: los endpoints directos al servicio (para servicios con un uso intensivo de rendimiento) y los endpoints de retransmisión de SCC (para la conectividad de clústeres seguros de computación clásica) aún deben configurarse por región.

Basado en el ingreso basado en el contexto

Estas nuevas capacidades de Inbound Private Link están integradas en los controles de ingreso basados en el contexto, que permiten a los administradores de cuentas escribir reglas detalladas de permiso y denegación basadas en quién realiza la llamada (identidad), desde dónde (origen de red: IP pública o endpoint registrado) y a qué se les permite acceder en el espacio de trabajo o recurso a nivel de cuenta (destino).

Las políticas para recursos a nivel de cuenta, como la consola de cuenta, se pueden definir en la nueva account-policy.

Las políticas de espacio de trabajo existentes tienen una nueva sección de “acceso privado” para la configuración de Inbound Private Link basada en el contexto.

Las políticas de Inbound Private Link tanto para el acceso general como para el acceso directo al servicio se pueden configurar en el ingreso basado en el contexto. Combinado con el soporte de acceso público existente, el ingreso basado en el contexto le ofrece un único motor de políticas para configurar el ingreso tanto público como privado para los espacios de trabajo y los recursos a nivel de cuenta.

Recomendamos a los clientes configurar el ingreso basado en el contexto en lugar de las listas de acceso de IP de todo o nada o la configuración de acceso privado (Private Access Settings) para aprovechar al máximo las últimas capacidades de nuestra plataforma.

Configuración mínima, sin interrupciones para los clientes existentes

Si ya utiliza Inbound Private Link, este lanzamiento es aditivo y no genera interrupciones. Las URL específicas del espacio de trabajo que no son personalizadas continúan funcionando en paralelo con el acceso a URL personalizadas. Las configuraciones de acceso privado y las listas de acceso de IP continúan funcionando en paralelo con el ingreso basado en el contexto (cualquier denegación de política provoca un rechazo).

Habilitar el acceso privado a los recursos a nivel de cuenta requiere dos pasos:

1. Registrar y agregar a la lista de permitidos un endpoint de acceso general para sus recursos a nivel de cuenta utilizando la account-policy de ingreso basada en el contexto.
2. Resolver mediante DNS su URL personalizada a ese endpoint de acceso general.

Primeros pasos

• Configure Inbound Private Link para recursos a nivel de cuenta (AWS, Azure)
• Obtenga más información sobre el control de ingreso basado en el contexto y la gestión de políticas de ingreso (AWS, Azure)
• Revise Inbound Private Link para espacios de trabajo (AWS, Azure) y Private Link directo al servicio (AWS, Azure)

Todas las nuevas capacidades de Inbound Private Link descritas aquí ya están disponibles en versión Beta en el nivel AWS Enterprise y el nivel Azure Premium. Los controles de ingreso basados en el contexto para el acceso público están disponibles de forma general. ¡Pruébelos hoy mismo!

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original