Concessão de permissões de instalação sem funções de cluster

Conceda ao instalador do Automation Suite permissões com escopo de namespace no OpenShift e componha as funções ausentes com escopo de cluster com recursos pré-criados.

Importante:

Esta página se aplica apenas quando sua política de segurança proíbe a concessão de quaisquer permissões com escopo de cluster (ClusterRole ou ClusterRoleBinding) à conta de serviço do instalador do Automation Suite (uipathadmin). Se você puder conceder as permissões com escopo de cluster, consulte Concedendo permissões de instalação com funções de cluster em vez disso.

Se você instalar várias instâncias do Automation Suite no mesmo cluster, você deve conceder permissões para os outros namespaces onde você instalar o Automation Suite.

Esta página descreve como conceder ao instalador do Automation Suite as permissões de que ele precisa sem atribuir nenhuma permissão com escopo de cluster.

Você mantém a conta de serviço uipathadmin estritamente com escopo de namespace: pula os dois recursos ClusterRole com escopo de cluster e o ClusterRoleBinding usados no fluxo padrão, e você compensar as leituras com escopo de cluster ausentes com um conjunto de pré recursos -criados e sinalizadores uipathctl.

Observação:

Você deve executar os comandos mencionados nesta seção em uma máquina Linux, Windows ou macOS que tenha acesso ao servidor da API OpenShift Kubernetes.

Os comandos que executam ações de administrador (criando o certificado Secret) devem ser executados por um administrador de cluster. Comandos que executam ações uipathadmin usam o kubeconfig que você gera na Etapa 4.

Para conceder permissões de instalação sem funções de cluster, execute as seguintes etapas:

1. Criação de uma conta de serviço
2. Criação das funções necessárias com escopo de namespace
3. Vinculando as funções
4. Gerando o arquivo kubeconfig
5. Configurando input.json para operação em modo restrito
6. Pré-criação do segredo do certificado TLS
7. Instalação e configuração do service mesh e da ferramenta GitOps

Etapa 1: criação de uma conta de serviço

Para criar uma conta de serviço, siga os seguintes passos:

1. Crie o namespace e o projeto <uipath> :

   oc get namespace <uipath> || oc new-project <uipath>
   

2. Defina o namespace e o projeto padrão como <uipath>:

   oc project <uipath>
   

   Todos os comandos oc subsequentes operarão dentro do namespace <uipath> .

3. Crie uma conta de serviço chamada uipathadmin:

   oc create serviceaccount uipathadmin
   

4. Use a função de cluster admin existente para conceder permissões de administrador à conta de serviço uipathadmin no namespace. <uipath>

   oc create rolebinding uipathadmin --clusterrole=admin --serviceaccount=<uipath>:uipathadmin
   

   Observação:

   Este é um RoleBinding com escopo de namespace que faz referência à função de cluster admin integrada. Ele concede permissões de administrador uipathadmin apenas dentro do namespace <uipath>, não em todo o cluster. Nenhum ClusterRoleBinding é criado.

Etapa 2: criação das funções com escopo de namespace necessárias

A conta de serviço uipathadmin requer certas permissões durante a instalação do Automation Suite. No fluxo sem funções de cluster, você fornece essas permissões apenas por meio de funções com escopo de namespace .

Para criar cada função, salve sua configuração como um arquivo YAML e execute o seguinte comando, substituindo o espaço reservado <file_name.yaml> pelo nome real do arquivo YAML:

oc apply -f <file_name.yaml>

Você pode criar o arquivo YAML para cada função copiando a configuração das seções a seguir.

As seguintes funções com escopo de namespace são as únicas funções de que uipathadmin precisa nesse fluxo. As verificações de pré-requisitos que, de outra forma, contariam com leituras com escopo de cluster são excluídas e validadas fora de faixa, conforme descrito em Execução de verificações de pré-requisitos sem funções de cluster.

Permissões de instalação no namespace <uipath>

A maior parte da instalação do Automation Suite é executada por meio do ArgoCD, mas alguns componentes são instalados diretamente por meio de gráficos do Helm. A ferramenta uipathctl executa um trabalho de instalação que executa essas instalações do Helm no namespace <uipath>. Para fazer isso, uipathadmin precisa de uma função com escopo de namespace que pode criar e gerenciar funções, associações de função, segredos e mapas de configuração.

O seguinte exemplo mostra a configuração uipath-automationsuite-role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: uipath-automationsuite-role
  namespace: <uipath>
rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "rolebindings"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
  - apiGroups: [""]
    resources: ["secrets", "configmaps"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
  - apiGroups: ["security.istio.io", "networking.istio.io"]
    resources: ["*"]
    verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]

Permissões de certificado e validação no namespace <istio-system>

Observação:

O namespace pode não existir em seu cluster se você ainda não instalou o Istio. Você pode criar o namespace e a função antes de instalar o Istio, ou você pode criar a função após instalar o Istio.

As seguintes operações são realizadas no namespace. <istio-system>

1. A ferramenta de verificação de pré-requisitos do Automation Suite lê os pods e serviços no namespace <istio-system> para validar se o Istio está instalado e configurado corretamente.
2. A permissão get secrets é necessária para copiar o arquivo de certificado do namespace <istio-system> para o namespace <uipath> .

Como uipathadmin não configura o Istio nem instala o plug-in do WebAssembly (WASM) no fluxo sem cluster, você usa a variante somente leitura dessa função. Um administrador de cluster executa essas operações (consulte a etapa 7).

O seguinte exemplo mostra a configuração istio-system-automationsuite-role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-system-automationsuite-role
  namespace: <istio-system>
rules:
  - apiGroups: [""]
    resources: ["services", "pods"]
    verbs: ["list"]
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["istio-ingressgateway-certs"]
    verbs: ["get"]

Etapa 3: vinculando as funções

Associe as funções com escopo de namespace que você criou na etapa anterior à conta de serviço uipathadmin executando os seguintes comandos:

oc project <istio-system>
oc create rolebinding istio-system-automationsuite-rolebinding \
  --role=istio-system-automationsuite-role --serviceaccount=<uipath>:uipathadmin
oc project <uipath>
oc create rolebinding uipath-automationsuite-rolebinding \
  --role=uipath-automationsuite-role --serviceaccount=<uipath>:uipathadmin

Etapa 4: geração do arquivo kubeconfig

Após atribuir todas as permissões à conta de serviço, você deve criar um arquivo kubeconfig para passar à ferramenta uipathctl para a instalação.

Gerando o arquivo kubeconfig no Linux ou Mac

Para gerar o arquivo kubeconfig no Linux ou Mac, execute os seguintes comandos:

# For generating kubeconfig
# Creates the token for uipathadmin service account
token=$(oc -n <uipath> create token uipathadmin --duration=8760h)
# Getting api-server details
server=$(oc config view -o jsonpath="{.clusters[]..server}")
# Login logs on using the provided token and server and outputs kubeconfig at the provided path.
oc login --server=$server --token=$token --kubeconfig=uipathadminkubeconfig --insecure-skip-tls-verify=true

Se a operação tiver sido bem-sucedida, você deverá ver um arquivo kubeconfig chamado uipathadminkubeconfig.

Gerando o arquivo kubeconfig no Windows

Observação:

Você deve executar essa etapa usando o Windows Powershell.

Para gerar o arquivo kubeconfig no Windows, execute os seguintes comandos:

# For generating kubeconfig
# Creates the token for uipathadmin service account
$token = oc -n <uipath> create token uipathadmin --duration=8760h
# Getting api-server details
$server = oc config view -o jsonpath="{.clusters[]..server}"
# Login logs on using the provided token and server and outputs kubeconfig at the provided path.
oc login --server=$server --token=$token --kubeconfig=uipathadminkubeconfig --insecure-skip-tls-verify=true

Se a operação tiver sido bem-sucedida, você deverá ver um arquivo kubeconfig chamado uipathadminkubeconfig.

Etapa 5: configuração de input.json para operação em modo restrito

No fluxo de funções sem cluster, você deve adicionar algumas chaves ao seu input.json para que uipathctl e os gráficos de serviço da UiPath evitem operações que exigem leituras ou recursos com escopo de cluster. As seções a seguir explicam cada tecla.

5.1 Classes de prioridade

Defina ignore_priority_class como true:

{
  "ignore_priority_class": true
}

Essa configuração faz o seguinte:

• Ele informa a uipathctl para ignorar sua própria pesquisa priorityclasses.scheduling.k8s.io, que, de outra forma, exigiria uma leitura com escopo de cluster.
• Ele se propaga para todos os gráficos de serviço da UiPath, que omitem priorityClassName de suas cargas de trabalho.

Como resultado, nenhum pod do Automation Suite faz referência a PriorityClass, portanto, nenhum PriorityClass precisa existir no cluster e nenhum deve ser pré-criado.

5.2 Certificados e ingresso

Adicione as chaves de certificado e ingresso. Para obter detalhes sobre as chaves relacionadas ao certificado, consulte Requisitos de certificado.

{
  "server_certificate": {
    "tls_cert_file": "<path-to-tls.crt>",
    "tls_key_file":  "<path-to-tls.key>",
    "ca_cert_file":  "<path-to-ca.crt>"
  },

  "ingress": {
    "namespace": "<istio-system>",
    "gateway_selector": { "istio": "ingressgateway" },
    "ingress_gateway_secret": "istio-ingressgateway-certs"
  },

  "additional_ca_certs": "<path-to-ca.crt>"
}

A chave additional_ca_certs é necessária apenas quando seu certificado TLS é assinado por uma Autoridade de Certificação particular ou autoassinada. Ele propaga o pacote da CA para o armazenamento de confiança de todos os pods do Automation Suite.

5.3 Limite de simultaneidade de Robôs AS

Importante:

Esta etapa é necessária apenas se você habilitar AS Robots (asrobots).

Se você habilitar o AS Robots, defina um concurrency_limit explícito:

{
  "asrobots": {
    "enabled": true,
    "concurrency_limit": 2
  }
}

Quando concurrency_limit não está definido, o gráfico AS Robots implanta um ClusterRole e ClusterRoleBinding para ler automaticamente a capacidade do nó e calcular a simultaneidade do robô. Uma instância do ArgoCD com namespace não pode gerenciar esses recursos com escopo de cluster, portanto, o aplicativo asrobots falha ao sincronizar:

ComparisonError: cluster level ClusterRoleBinding "<uipath>-asrobots-robot-resources-crb" can not be managed when in namespaced mode

Com um concurrency_limit explícito, o gráfico não implanta recursos com escopo de cluster.

5.4 Traga seus próprios componentes

Como uipathadmin não tem permissões com escopo de cluster nesse fluxo, o instalador não pode implantar os componentes da plataforma que criam recursos com escopo de cluster - como Istio, OPA Gatekeeper, cert-manager e políticas de rede. Você deve provisionar esses componentes por conta própria e listá-los em exclude_components para que o instalador os ignore.

Liste os componentes que você fornece em exclude_components e defina telemetry_optout como true, porque a telemetria não pode ser habilitada neste fluxo. Para obter a lista e detalhes de componentes, consulte Sem funções de cluster.

Etapa 6: pré-criação do segredo do certificado TLS

Como uipathadmin é apenas com escopo de namespace, um administrador de cluster deve criar o istio-ingressgateway-certs Secret no namespace <istio-system> antes da instalação. Isso não concede a uipathadmin nenhum privilégio extra; ele substitui o trabalho que uipathadmin teria feito se tivesse as permissões com escopo de cluster. (Nenhum PriorityClass precisa ser criado - essa dependência é removida por ignore_priority_class na Etapa 5.1.)

O istio-ingressgateway-certs Secret é criado como parte da configuração do service mesh. Para criá-lo, consulte Configuração do Istio e instalação do plug-in do WASM para roteamento.

Como uipathadmin contém apenas istio-system-automationsuite-role somente leitura, ele pode ler Secret mas não pode criá-lo; um administrador de cluster deve criá-la.

Certifique-se de que a Secret contenha todas as três chaves - tls.crt, tls.key e ca.crt - porque a chave ca.crt é necessária quando seu certificado TLS é assinado por uma Autoridade de Certificação particular ou autoassinada.

Etapa 7: Instalação e configuração do service mesh e da ferramenta GitOps

Siga os procedimentos padrão para o service mesh e a ferramenta GitOps. Esses procedimentos criam funções e associações adicionais com escopo de namespace para uipathadmin no namespace <argocd>; nenhum deles requer permissões com escopo de cluster em uipathadmin.

• Instalação e configuração do service mesh - instale o OpenShift Service Mesh. Como uipathadmin é executado com a função somente leitura <istio-system>, ele não pode configurar o Istio ou instalar o próprio plug-in do WASM; um administrador de cluster deve configurar istio-configure antes da instalação do Automation Suite.
• Instalação e configuração da ferramenta GitOps - provisione a instância dedicada do ArgoCD e conclua todas as etapas.

Para as istio-configure etapas de configuração, consulte Configuração do Istio e instalação do plug-in do WASM para roteamento.