Automatizando com Controle: Gerenciando Usuários e Permissões no Rundeck

Introdução

Em ambientes modernos de DevOps e operações de infraestrutura, a automação não é apenas uma vantagem, mas uma necessidade. Entre as diversas ferramentas que surgiram para orquestrar tarefas, o Rundeck se destaca por sua simplicidade, flexibilidade e, principalmente, por ser multiusuário e multitarefa, com um robusto sistema de controle de acesso.

Neste post, vamos apresentar o que é o Rundeck, como ele funciona, como organizar e automatizar tarefas com ele e como implementar um sistema eficiente de controle de acessos baseado em grupos e políticas ACL (Access Control List), explorando de forma mais aprofundada as opções de permissão e como organizar essas políticas para times diferentes.

O que é o Rundeck?

O Rundeck é uma plataforma open-source para automação de operações, permitindo executar scripts, comandos e workflows em servidores ou containers remotamente. Com ele, é possível:

• Agendar execuções recorrentes de tarefas
• Executar comandos sob demanda (ad-hoc)
• Criar workflows com etapas e dependências
• Integrar com ferramentas como Ansible, Puppet, Terraform e scripts customizados
• Controlar o acesso de usuários por projeto e por tipo de ação
• Auditar todas as ações realizadas na plataforma

O Rundeck pode ser integrado a sistemas de autenticação como LDAP, Active Directory ou Keycloak, garantindo controle centralizado de identidade e segregação por função.

Multitarefa e Multiusuário

O Rundeck permite que vários usuários interajam simultaneamente na plataforma, cada um com permissões específicas por projeto. Cada execução de job é isolada e registrada, permitindo:

• Execuções paralelas com segurança
• Controle de acesso por grupo (Ex: Dev, QA, Operações)
• Logs detalhados por execução e por usuário

Essa capacidade de isolamento e rastreabilidade o torna ideal para ambientes corporativos que exigem governança.

Estrutura básica: Projetos, Jobs e Nós

Projeto – É a unidade lógica que organiza os jobs, o inventário de nós (hosts) e as permissões. Cada projeto é independente e pode ter fontes de inventário e configurações próprias.

Job – Representa uma tarefa automatizada. Pode conter:

• Execução de scripts (bash, Python, etc.)
• Comandos remotos
• Workflows com múltiplos passos

Nó (Node) – É um host de destino onde os comandos serão executados. Pode ser um servidor físico, uma máquina virtual, container ou qualquer endpoint SSH.

Gerenciando Acessos com Políticas ACL

O que são ACLs no Rundeck?

ACLs (Access Control Lists) são arquivos YAML com extensão .aclpolicy, que definem:

• Quem pode acessar (usuários ou grupos)
• O que pode acessar (jobs, nós, projetos, etc.)
• O que pode fazer (read, run, update, kill, etc.)

Esses arquivos ficam normalmente no diretório:

/etc/rundeck/ ou /home/rundeck/etc/

Estrutura geral de uma ACL

description: Acesso para o time DevOps
context:
project: 'WebApps'
for:
job:
- allow: [read, run, create, update, delete, kill]
node:
- allow: [read, run, create, update, delete]
adhoc:
- allow: [read, run, kill]
resource:
- allow: [read]
by:
group: devops-team

Explicação das principais seções

context:
Define o escopo da permissão:
– project: ‘NomeDoProjeto’ – aplica regras apenas dentro do projeto
– application: ‘rundeck’ – aplica regras globais (criação de projetos, visualização de usuários, etc.)

for:
Lista os tipos de recursos que serão controlados. Os principais:
– job – jobs definidos no projeto
– node – nós (servidores ou hosts)
– adhoc – comandos ad-hoc (ex: `hostname`)
– resource – acesso a arquivos e elementos do projeto
– project – configurações gerais do projeto
– project_acl – editar ACLs de projeto
– storage – secrets e senhas armazenadas

allow:
Lista as ações permitidas para o recurso. As mais comuns são:
– read – visualizar
– run – executar
– create – criar
– update – editar
– delete – remover
– kill – cancelar uma execução em andamento

by:
Define quem receberá as permissões:
– group – nome do grupo de usuários
– username – (opcional) pode restringir por usuário específico

Exemplo completo para múltiplos times

Time de QA (apenas leitura e execução)

description: Acesso limitado para QA
context:
project: 'TestesAPI'
for:
job:
- allow: [read, run]
node:
- allow: [read]
adhoc:
- allow: [read, run]
by:
group: qa-team

Time de Operações (administra tudo)

description: Admin do projeto
context:
project: 'TestesAPI'
for:
job:
- allow: [*]
node:
- allow: [*]
adhoc:
- allow: [*]
resource:
- allow: [*]
project:
- allow: [read, configure]
by:
group: ops-team

Time de Desenvolvimento (pode rodar e alterar seus próprios jobs)

description: Desenvolvedores com acesso RW
context:
project: 'WebFrontend'
for:
job:
- allow: [read, run, create, update, kill]
node:
- allow: [read, run]
adhoc:
- allow: [read, run, kill]
by:
group: developers

Boas práticas para aplicar ACLs

• Nomear arquivos ACL com o nome do grupo (ex: qa-team.aclpolicy)
• Separar por escopo: um arquivo por projeto ou grupo
• Usar regex para escalar (ex: project: ‘^(Web|API)_.*$’)
• Testar com usuários reais antes de aplicar em produção
• Versionar todos os arquivos ACL com Git

Conclusão

O Rundeck é uma plataforma poderosa para automação controlada e colaborativa. Seu modelo de ACL permite configurar com precisão quem pode fazer o quê dentro da plataforma, garantindo segurança, governança e autonomia. Organizar bem suas políticas ACL é o segredo para escalar o uso do Rundeck com confiança, permitindo que diferentes equipes contribuam de forma segura, sem sobreposição ou riscos operacionais. Se você está buscando uma forma de dar mais autonomia para seus times sem perder controle, o Rundeck com ACL bem definidas pode ser a chave para transformar a maneira como você opera sua infraestrutura.