O Inbound Private Link agora suporta o Genie One no nível da conta, o console da conta e URLs personalizadas

As empresas que adotam o Databricks para seus dados mais confidenciais geralmente dependem do Inbound Private Link para manter o tráfego do usuário para o Databricks fora da internet pública, roteando-o de forma privada por meio de sua própria rede em nuvem. À medida que os clientes escalam para muitos workspaces, várias regiões e produtos no nível da conta, como o Genie One, estendemos os recursos do Inbound Private Link para atendê-los nessas necessidades.

O que há de novo no Inbound Private Link

O Inbound Private Link agora suporta recursos no nível da conta, incluindo o Genie One no nível da conta, o console da conta, o Governance Hub e APIs no nível da conta. Os clientes podem colocar o Genie One no nível da conta atrás do Inbound Private Link com as mesmas garantias de rede que já aplicam em todos os outros lugares.

O Inbound Private Link agora suporta URLs personalizadas e URLs estáveis de Recuperação de Desastres Gerenciada. O Inbound Private Link agora funciona de ponta a ponta com URLs personalizadas, como acme.databricks.com. Isso se estende a URLs estáveis de recuperação de desastres gerenciada (por exemplo, acme.databricks.com/?c=stable-ws-id).

Um único endpoint, qualquer região, para cada recurso de UI + API. Um único endpoint de Acesso Geral compartilhado em qualquer região agora pode atender a todas as UIs + APIs de workspace e no nível da conta. Os clientes não precisam mais criar um endpoint por região ou workspace. Equipes com requisitos rígidos de isolamento de rede ainda podem usar vários endpoints; mas esses endpoints não estão mais limitados a atender recursos na mesma região. Isso reduz o esforço manual e o custo necessários para manter muitos endpoints. Observação: os endpoints service-direct (para serviços de uso intensivo de desempenho) e os endpoints de relay SCC (para conectividade segura de clusters de computação clássica) ainda precisam ser configurados por região.

Criado com base no ingresso baseado em contexto

Esses novos recursos do Inbound Private Link são integrados aos controles de ingresso baseados em contexto, que permitem que os administradores de conta criem regras detalhadas de permissão e negação com base em quem está chamando (identidade), de onde (origem da rede: IP público ou endpoint registrado) e o que eles têm permissão para acessar no workspace ou recurso no nível da conta (destino).

As políticas para recursos no nível da conta, como o console da conta, podem ser definidas na nova account-policy.

As políticas de workspace existentes têm uma nova seção de “acesso privado” para a configuração do Inbound Private Link baseado em contexto.

As políticas do Inbound Private Link para acesso geral e service-direct podem ser configuradas no ingresso baseado em contexto. Combinado com o suporte de acesso público existente, o ingresso baseado em contexto oferece um único mecanismo de política para configurar o ingresso público e privado para workspaces e recursos no nível da conta.

Recomendamos que os clientes configurem o ingresso baseado em contexto em vez de listas de acesso IP do tipo "tudo ou nada" ou Configurações de Acesso Privado para aproveitar ao máximo os recursos mais recentes da nossa plataforma.

Configuração mínima, sem interrupções para clientes existentes

Se você já usa o Inbound Private Link, esta versão é cumulativa e não causa interrupções. URLs específicas de workspace não personalizadas continuam funcionando em paralelo com o acesso a URLs personalizadas. As configurações de acesso privado e as listas de acesso IP continuam funcionando em paralelo com o ingresso baseado em contexto (qualquer negação de política leva à rejeição).

A ativação do acesso privado a recursos no nível da conta exige duas etapas:

1. Registre e inclua na lista de permissões um endpoint de Acesso Geral para seus recursos no nível da conta usando a account-policy de ingresso baseado em contexto.
2. Faça a resolução de DNS da sua URL personalizada para esse endpoint de Acesso Geral.

Primeiros passos

• Configure o Inbound Private Link para recursos no nível da conta (AWS, Azure)
• Saiba mais sobre o controle de ingresso baseado em contexto e o gerenciamento de políticas de ingresso (AWS, Azure)
• Revise o Inbound Private Link para workspaces (AWS, Azure) e o Private Link service-direct (AWS, Azure)

Todos os novos recursos do Inbound Private Link descritos aqui já estão disponíveis em Beta nas camadas AWS Enterprise e Azure Premium. Os controles de ingresso baseados em contexto para acesso público estão em Disponibilidade Geral. Experimente ambos hoje mesmo!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original