Controle de acesso

Nesta página, descrevemos como controlar o acesso a instâncias do Filestore.

  • Com o protocolo NFSv4.1, é possível usar o Kerberos para proteger o acesso a instâncias do Filestore. Para mais informações, consulte Sobre os protocolos compatíveis.

  • Como alternativa, use as opções do Linux para controlar o acesso ao NFS e o gerenciamento de identidade e acesso (IAM) para controlar o acesso às operações de instância, como criar, editar, visualizar e excluir instâncias. O guia a seguir mostra como concluir cada uma dessas tarefas.

Configurações de exportação de compartilhamento de arquivos

Um compartilhamento de arquivos do Filestore é atribuído às seguintes configurações padrão de /etc/exports:

  • A lista de clientes, que identifica os clientes com permissão para se conectar ao compartilhamento de arquivos, contém todos os endereços IP internos na rede VPC selecionada para a instância do Filestore. Os endereços IP internos podem ser qualquer intervalo listado em intervalos de sub-rede. No entanto, se você tiver clientes em intervalos de sub-redes não RFC 1918, será necessário conceder explicitamente o acesso à instância do Filestore usando o controle de acesso baseado em IP.
  • A opção rw é usada. Portanto, o compartilhamento de arquivos permite operações de leitura e gravação.
  • A opção de mapeamento de ID do usuário no_root_squash é usada. Portanto, espera-se que todos os usuários e grupos, incluindo o usuário raiz, sejam os mesmos na instância do Filestore e no cliente.
  • Todas as outras opções usam os padrões /etc/exports.

Instâncias de nível básico

As instâncias SSD básico e HDD criam um compartilhamento exportado com o nome /config/google-prober, usado para ajudar a suportar processos de sondagem interna, que, por sua vez, verificam o acesso, a durabilidade ou o desempenho. A partição é exportada para uma lista de clientes acessível apenas ao endereço IP da instância, usando as mesmas configurações indicadas na seção anterior. A partição é acessível apenas a sondas hospedadas ou originadas na instância e fica inacessível fora dela. A instância exporta a ação, independentemente de o controle de acesso baseado em IP ser aplicado. Os usuários podem acessar o compartilhamento exportado usando o comando showmount -e.

Controle de acesso baseado em IP

É possível alterar essas configurações de exportação criando regras de controle de acesso usando o console do Google Cloud ou especificando um arquivo de configuração JSON durante a criação da instância usando a CLI gcloud. Para mais detalhes, consulte Como configurar o controle de acesso baseado em IP.

Também é possível adicionar novas regras de controle de acesso ou modificar as existentes depois que uma instância é criada. Para detalhes, consulte Como editar instâncias.

Permissões de compartilhamento de arquivos

Quando você cria uma instância do Filestore, o compartilhamento de arquivos para essa instância tem permissões de arquivo POSIX padrão de rwxr-xr-x. Essas permissões significam que, em uma instância do Filestore, somente usuários raiz em clientes conectados têm acesso de leitura e gravação ao compartilhamento de arquivos. Outros usuários só têm acesso de leitura por padrão. Os usuários raiz do cliente podem alterar permissões e proprietários.

Como configurar o acesso em um compartilhamento de arquivos

Ao ativar um compartilhamento de arquivos, use as opções de ativação e as configurações de /etc/fstab para determinar se o compartilhamento de arquivos é gravável e se os arquivos podem ser executados nele. Depois de ativar o compartilhamento de arquivos, use os comandos padrão do Linux, como chmod e setfacl para definir permissões de arquivo e compartilhamento de arquivos. Somente as camadas básicas são compatíveis com setfacl.

Como definir permissões consistentes

É altamente recomendável definir permissões consistentes para cada usuário em todos os clientes que se conectam à mesma instância do Filestore para evitar o escalonamento de privilégios. Se um compartilhamento de arquivos for ativado em mais de um cliente, e um usuário tiver privilégios de raiz em um cliente, mas não nos outros, o seguinte cenário de escalonamento de privilégios será possível:

  • Um usuário define o atributo setuid em um arquivo executável do cliente em que o usuário tem acesso de raiz.
  • Em seguida, o usuário faz upload do arquivo executável para o compartilhamento de arquivos.
  • O usuário executa o arquivo enviado como raiz em qualquer cliente em que ele tenha pelo menos a permissão de leitura.

Esse cenário é possível porque o bit setuid permite que o usuário execute um arquivo usando as permissões do proprietário, que, neste caso, é raiz.

Permissões sobrepostas

As instâncias zonais, regionais e corporativas agora oferecem suporte a permissões sobrepostas.

Se duas regras de controle de acesso separadas forem definidas para sub-redes de endereços IP sobrepostas, a regra definida para a sub-rede menor terá prioridade.

Por exemplo, se um arquivo de configuração JSON contiver uma regra que concede acesso de leitura e gravação para a sub-rede de endereço IPv4 10.0.0.0/24 e uma regra separada conceder acesso somente leitura para a sub-rede de endereço IPv4 10.0.0.0/28, o Filestore reconhece e aplica a regra para a sub-rede menor primeiro. A outra regra é aplicada às partes restantes da sub-rede de endereços IP definida. Neste exemplo, um cliente que usa o endereço IPv4 10.0.0.20 recebe permissões de leitura e gravação, enquanto um cliente que usa 10.0.0.12 recebe permissões somente leitura:

   {
  "--file-share":
    {
      "capacity": "2048",
      "name": "my_vol",
      "nfs-export-options": [
        {
          "access-mode": "READ_WRITE",
          "ip-ranges": [
            "10.0.0.0/24"
          ],
          "squash-mode": "ROOT_SQUASH",
          "anon_uid": 1003,
          "anon_gid": 1003
        },
         {
          "access-mode": "READ_ONLY",
          "ip-ranges": [
            "10.0.0.0/28"
          ],
          "squash-mode": "NO_ROOT_SQUASH"
        }
      ]
    }
}

Sujeito a algumas restrições:

  • Permissões sobrepostas para sub-redes IPv4 idênticas não são aceitas e retornam um erro.

  • Não há suporte para permissões sobrepostas em instâncias básicas de SSD ou HDD.

A seguir