eu faria isso via sudo
user1 ALL=(root) /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2 ALL=(root) /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
Eu tenho um pool de servidores DNS autoritativos que precisam hospedar zonas para 5 usuários, cada um com entre 2 e 10 zonas.
Cada usuário pode ssh para os servidores usando a autenticação de chave pública. Os requisitos que estou enfrentando dizem que desde que o usuário possa se conectar à porta ssh no servidor, eles também devem poder atualizar suas próprias zonas sem depender de qualquer outra comunicação de rede .
O que eu fiz até agora é configurar cada zona a ser carregada a partir do diretório inicial do usuário que possui a zona, como neste exemplo:
zone "example.com" {
type master;
file "/home/example/zones/example.com";
};
Não sei se existe alguma recomendação sobre o carregamento de arquivos de zona diretamente do diretório pessoal de um usuário. Tentei algumas pesquisas e não encontrei recomendações a favor ou contra essa prática.
Parece funcionar, mas as alterações só entram em vigor depois que eu reiniciei ou recarreguei o bind, que atualmente tenho que fazer como root.
A distribuição que estou usando fornece BIND 9.8 com patches de segurança. Então baixei a versão 9.8 do "BIND 9 Administrator Reference Manual" para procurar maneiras de um usuário instruir a ligação para recarregar uma zona.
Eu encontrei o comando rndc
, no entanto, parece que os controles de acesso no BIND não são refinados o suficiente para permitir que um segredo seja usado apenas para recarregar uma zona específica. Eu posso especificar combinações de endereços IP e acesso secreto aos segredos HMAC-MD5, mas qualquer combinação permitida de acesso será permitida para invocar todos os comandos através de rndc
.
Como posso permitir que um usuário recarregue seus arquivos de zona sem conceder a eles outros direitos administrativos?
Neste ponto, estou pensando que eu poderia usar sudo
ou a opção command
em .ssh/authorized_keys
para conceder ao usuário acesso para invocar um comando rndc
específico.
Esta é uma abordagem aconselhável ou devo estar fazendo outra coisa?
Eu também considerei o uso de transferências de zona. Mas minha compreensão de como as transferências de zona funcionam é que o servidor DNS de recebimento atua como cliente na transferência de zona e o servidor DNS de envio age como servidor. Se meu entendimento estiver correto, significa que ter um cliente fornecendo uma nova versão da zona para o servidor não é possível. Então, parece que se eu fosse usar essa abordagem, eu teria que usar uma configuração de mestre oculto com esse mestre oculto rodando em um cliente VPN, o que, por razões que não posso formular, parece errado.
eu faria isso via sudo
user1 ALL=(root) /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2 ALL=(root) /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
Você pode pedir a seus clientes que usem uma ferramenta rcs, como o git, para atualizar seus arquivos de zona e enviá-los para os respectivos homedirs. Lá, crie um repositório git com um hook de recebimento de post que executa esses comandos usando as regras de sudo que o user1700494 indica (eu adicionaria named-checkzone e named-checkconf também).
Por questões de integridade, aqui estão as regras do sudo user1700494 sugeridas
user1 ALL=(root) /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2 ALL=(root) /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
Dessa forma, você mantém tudo no controle de versão para que possa voltar facilmente, se necessário, e seus usuários não precisam efetuar login e modificar arquivos no servidor, tudo pode ser feito em seu próprio ambiente. Além disso, você só recarrega o servidor depois de verificar se os arquivos estão corretos.
Eu aconselharia cada instância de ligação a ser executada em um LXC. Cada usuário possui sua própria instância de vinculação. Forneça-lhes as credenciais de suas respectivas instâncias.
Tags bind