Read this article in English.
Ao adicionar um novo node a um cluster OpenShift (OCP), você pode encontrar o Machine Config Server (MCS) recusando conexões na porta 22623. Essa proteção, introduzida a partir do OpenShift 4.5, evita o acesso indevido a configurações sensíveis, mas também pode impedir que nodes worker e control plane obtenham os arquivos necessários.
Neste artigo, explico por que isso acontece, como o comportamento afeta a inclusão de novos nodes e como automatizei o ajuste com um script.
O problema: conexão recusada pelo MCS
Durante a inclusão, o novo node precisa buscar sua configuração no Machine Config Server. Nesse momento, pode aparecer um erro como este:
# curl -kv https://api.test.mydomain.example.com:22623/config/worker
* Trying 192.168.1.1...
* TCP_NODELAY set
* connect to 192.168.1.1 port 22623 failed: Connection refused
* Failed to connect to api.test.mydomain.example.com port 22623: Connection refused
* Closing connection 0
curl: (7) Failed to connect to api.test.mydomain.example.com port 22623: Connection refusedO detalhe curioso é que a mesma URL pode responder a partir de um bastion host, mas não dos próprios nodes do OpenShift.
Por que isso acontece
A partir do OCP 4.5, o OpenShift passou a bloquear automaticamente o acesso interno à porta 22623 por meio de regras do iptables. A medida impede que pods com privilégios elevados acessem configurações sensíveis dos nodes.
Para verificar se os nodes foram afetados, execute:
iptables -L | grep 22623A saída provavelmente será parecida com esta:
REJECT tcp -- anywhere anywhere tcp dpt:22623 flags:FIN,SYN,RST,ACK/SYN reject-with icmp-port-unreachableEssa regra bloqueia explicitamente o tráfego na porta 22623 e impede que os nodes obtenham suas configurações.
Por que o OpenShift bloqueia essa porta
- Medida de segurança: impede que containers privilegiados acessem machine configs sem autorização.
- Hardening do cluster: reduz a superfície de ataque para ameaças internas.
- Efeito colateral: pode interromper o bootstrap e a inclusão de novos nodes.
Impacto na inclusão de nodes
Quando um novo node não consegue acessar o Machine Config Server, ele:
- Não obtém sua configuração do Ignition.
- Fica preso durante o provisionamento.
- Não entra no cluster e permanece em estado não pronto.
Em clusters que passam por expansão frequente ou possuem onboarding automatizado de nodes, esse comportamento bloqueia todo o processo.
Solução: removendo as regras de firewall
Para que os novos nodes obtenham suas configurações, precisamos remover as regras do iptables que bloqueiam a porta 22623.
Ajuste manual
Em um único node, a regra pode ser removida manualmente:
iptables -D FORWARD -p tcp --dport 22623 -j REJECT
iptables -D OUTPUT -p tcp --dport 22623 -j REJECTO problema é que essa abordagem não escala em clusters maiores.
Ajuste automatizado com um script
Para automatizar a mudança em todos os nodes, criei um script Bash que:
- Identifica todos os nodes do cluster.
- Detecta se cada node utiliza iptables ou nftables.
- Remove as regras de bloqueio em cada node.
- Permite que todos os nodes alcancem o MCS sem intervenção manual.
Repositório no GitHub
Para utilizar o script, clone o repositório e execute-o a partir da sua máquina:
Etapa 1: clone o repositório
git clone https://github.com/Gabrielandre02/openshift-iptables-22623
cd openshift-iptables-22623/EN-US/Etapa 2: conceda permissão de execução
chmod +x iptables-openshift-22623.shEtapa 3: execute o script
./iptables-openshift-22623.shObservação importante
Antes de executar o script, confirme que o oc está autenticado na API do cluster OpenShift:
oc login https://your-openshift-api:6443 -u <your-username> -p <your-password>
Depois da autenticação, o script remove as regras que bloqueiam a porta 22623. Com isso, os novos nodes conseguem obter suas configurações e entrar no cluster.
Validando o ajuste
Se o comando não retornar resultados, a regra foi removida.
Em seguida, teste o acesso ao Machine Config Server:
curl -kv https://api.test.mydomain.example.com:22623/config/workerCom o acesso restabelecido, você pode continuar o processo de inclusão dos novos nodes no cluster.
💡 Quem sou eu?
Sou Gabriel Carmo, CNCF Kubestronaut, com certificações CKA, CKAD, CKS, KCNA e KCSA, além de Red Hat Certified OpenShift Administrator.
Atuo em DevOps Engineering, construindo e evoluindo plataformas Kubernetes multi-cloud. Meu trabalho tem como foco reduzir a carga cognitiva das equipes de engenharia por meio de platform engineering, automação, GitOps e experiências self-service.
No dia a dia, conecto infraestrutura como código, cloud networking, governança, segurança, observabilidade e práticas de SRE para criar plataformas mais padronizadas, resilientes e fáceis de operar.