Introdução
Ao trabalhar com Oracle FPP, quando o servidor de destino é um FPP Target gerenciado com um FPP Client devidamente configurado, a autenticação ocorre automaticamente entre o FPP Server e o FPP Client nas operações com comandos “rhpctl” ou REST API.
No entanto, a opção de ter um FPP Client só é suportada quando o servidor de destino possui o Oracle Clusterware, o que em termos práticos, significa dizer que só funciona com Oracle RAC na maioria dos casos. Então quando o destino é um servidor Single (ORACLERESTART ou STANDALONE), o FPP trata o servidor como um FPP Target não gerenciado, e requisita que a senha do root, ou de um usuário com permissão de sudo seja fornecida durante as operações.
Também podemos utilizar uma chave SSH para realizar a autenticação ao invés de forncer uma senha, o que pode ser uma alternativa de segurança dependendo da política do ambiente, ou até mesmo para suportar padrões de configurações como Compute Instances na OCI que tem um usuário “opc” como padrão.
Opcionalmente, mas recomendado, temos a opção de criar credenciais nomeadas dentro do FPP Server, e fazer referência ao nome dessa credencial nos comandos rhpctl ou requisições de REST API. Na prática funciona de forma muito similar as credenciais do Enterprise Manager, onde não precisamos ficar digitando a senha do banco de dados toda vez que o OEM precisa se reconectar.
Assim como na autenticação ad-hoc, a criação de uma credencial também suporta acesso direto com root ou com outro usuário que tenha privilégio de sudo. No entanto, não é possível criar uma credencial usando uma chave SSH.
Se tentarmos executar qualquer comando com rhpctl em um FPP Target não gerenciado, sem fornecer qualquer uma dessas opções de autenticação, receberemos um erro como este:
PRCG-1054 : The "-targetnode" option requires the specification of "-root" or "-cred" or "-sudouser" or "-auth" option.Este post demonstra as diferentes opções de autenticação disponível no FPP Server 19c, incluindo como criar e modificar uma credencial, assim como exemplo de utilização nos comandos rhpctl e REST API.
1) Autenticação com Senha
Quando a autenticação for direto com usuário root, basta informar a opção -root na linha de comando, e o FPP solicitará a senha após a confirmação do comando (ENTER)
Exemplo:
[grid@fppserver ~]$ rhpctl add workingcopy -targetnode lab01 -root -workingcopy WC_GI1922_lab01 -image GI1922 -path /u01/app/19.0.0/GI1922 -softwareonly -eval Enter user "root" password:
Quando a autenticação for com algum outro usuário que tenha privilégio de sudo, precisamos informar o nome do usuário no parâmetro –sudouser, e o caminho do binário do “sudo” no parâmetro -sudopath, como no exemplo abaixo:
rhpctl add workingcopy -targetnode lab01 -sudouser ansible -sudopath /usr/bin/sudo ...
Uma das limitações da autenticação com senha é que não podemos utilizá-la com a opção de agendamento do FPP. A opção -schedule cria um JOB para a operação que estamos realizando e o executa em background, permitindo que várias operações sejam executadas em paralelo (Um JOB para cada operação).
Ao tentar combinar essas duas opções, você receberá um erro como este:
PRCG-1055 : The options "-schedule" and "-root" can not be specified together.Se estiver usando REST API, o JSON body para autenticação com root deve conter algo assim:
{
"patchedwc" : "WC_DB1921_lab02",
"targetNode" : "lab02",
"root" : "true",
"superUserPasswd": "Senha",
"eval" : "false"
}
E se for com outro usuário com privilégio sudo, o JSON ficaria assim:
{
"patchedwc" : "WC_DB1921_lab02",
"targetNode" : "lab02",
"sudoUser": "ansible",
"sudoPath": "/usr/bin/sudo",
"superUserPasswd": "Senha",
"eval" : "false"
}
Contra recomendo usar essa opção via REST API pois a senha fica exposta no JSON body.
2) Autenticação com Chave SSH
O pré requisito para esta abordagem é ter a chave privada do usuário, disponível no FPP Server.
Para autenticar com uma chave SSH, precisamos usar o parâmetro “-auth” com o valor “sshkey”, e adicionar os seguintes parâmetros:
- –arg1 user:<nome do usuário>
- –arg2 identity_file:<caminho da chave privada>
- –arg3 sudo_location:<caminho do binário sudo no FPP Target>
Exemplo com o usuário “opc” e a chave privada localizada em “/home/grid/lab01_opc.key” no FPP Server:
rhpctl add workingcopy -auth sshkey -arg1 user:opc -arg2 identity_file:/home/grid/lab01_opc.key -arg3 sudo_location:/usr/bin/sudo
Exemplo da opção de autenticação por chave SSH combinada com o parâmetro -schedule para executar a operação em background:
[grid@fppserver ~]$ rhpctl add workingcopy -targetnode lab01 -auth sshkey -arg1 user:opc -arg2 identity_file:lab01_opc.key -arg3 sudo_location:/usr/bin/sudo -image GI1922 -workingcopy WC_GI1922_lab01 -path /u01/app/19.0.0/GI1922 -oraclebase /u01/app/grid -softwareonly -eval -schedule NOW Operation "rhpctl add workingcopy" scheduled with the job ID "35".
O atributo “identity_file” não suporta caminho relativo do arquivo, se você tentar usar esse tipo de sintaxe receberá um erro como este:
PRCZ-4016 : the path "~/lab01_opc.key" is not a fileExemplo de JSON Body com REST API, note que precisamos adicionar os atributos “auth” e “authArgs”, sendo que este segundo recebe um sub-documento JSON como valor, contendo uma combinação de chave e valor para cada um dos argumentos que vimos anteriormente na linha de comando.
{
"path" : "/u01/app/19.0.0/GI1922",
"imageName" : "GI1922",
"workingcopy" : "WC_GI1922_lab01",
"targetNode" : "lab01",
"auth" : "sshkey",
"authArgs": {
"arg1" : "user:opc",
"arg2" : "identity_file:/home/grid/lab01_opc",
"arg3" : "sudo_location:/usr/bin/sudo"
},
"softwareOnly": true,
"eval" : true
}
3) Autenticação com Credencial Nomeada
Para utilzar esse recurso, precisamos primeiro criar uma credencial no FPP com o comando “rhpctl add credentials”. Essa credencial é armazenada de forma criptografada dentro do OCR (Oracle Cluster Registry) do Clusterware onde o FPP Server está executando.
Opções do comando:
[grid@fppserver ~]$ rhpctl add credentials -h
Adds credentials to the OCR.
Usage: rhpctl add credentials -cred <cred_name>
{-root |
-sudouser <sudo_user_name> -sudopath <sudo_binary_location>}
-cred <cred_name> Credential name to associate the user/password credentials to access a remote node
-root Use root credentials to access the remote node
-sudouser <username> perform super user operations as sudo user name
-sudopath <sudo_binary_path> location of sudo binary
Criando uma credencial para usuário root:
[grid@fppserver ~]$ rhpctl add credentials -cred dibiei_root -root Enter user "root" password: fppserver.dibiei.com: Audit ID: 234
Após digitar o comando, o FPP irá solicitar a senha para ser atribuída a credencial. Um ponto de atenção nesta etapa é que ele não solicita a confirmação da senha, então recomendo testar a credencial assim que ela for criada.
Criando uma credencial para um usuário que tem privilégio sudo:
[grid@fppserver ~]$ rhpctl add credentials -cred dibiei_ansible -sudouser ansible -sudopath /usr/bin/sudo Enter user "ansible" password: fppserver.dibiei.com: Audit ID: 235
Consultando as credenciais criadas no FPP:
[grid@fppserver ~]$ rhpctl query credentials fppserver.dibiei.com: Audit ID: 236 fppserver.dibiei.com: Credentials found: 3 fppserver.dibiei.com: Credential name: dibiei_root fppserver.dibiei.com: Credential name: dibiei_ansible fppserver.dibiei.com: Credential name: cred_cluster01
Para utilizar a credencial, basta informar o parâmetro -cred em todos os comandos rhpctl e informar o nome de uma credencial válida.
Exemplo utilizando a credencial “dibiei_root” na operação de DELETE WORKINGCOPY:
[grid@fppserver ~]$ rhpctl delete workingcopy -workingcopy WC_GI1922_lab01 -targetnode lab01 -cred dibiei_root fppserver.dibiei.com: Audit ID: 230 fppserver.dibiei.com: Executing detach home operation... lab01: Starting Oracle Universal Installer... lab01: lab01: Checking swap space: must be greater than 500 MB. Actual 4091 MB Passed lab01: The inventory pointer is located at /etc/oraInst.loc lab01: You can find the log of this install session at: lab01: /u01/app/oraInventory/logs/DetachHome2024-04-24_09-22-03PM.log lab01: 'DetachHome' was successful. fppserver.dibiei.com: Successfully executed detach home operation. fppserver.dibiei.com: Removing storage for working copy ...
Se for via REST API, em quase todos os JSON (com exeção dos relacionados a FPP Client gerenciado), terá a opção de adicionar este atributo:
{
"patchedwc" : "WC_DB1921_lab02",
"targetNode" : "lab02",
"cred" : "dibiei_root",
"eval" : "false"
}
Modificando uma Credencial
Intuitivamente você pode pensar em utilizar o comando “rhpctl modify credentials” para modificar uma credencial, ou atualizar a senha armazenada na mesma, mas essa operação não é suportada:
[grid@fppserver ~]$ rhpctl modify credentials -cred dibiei_root
PRCG-1081 : Command "modify" is not supported for object "credentials"Então para modificar uma credencial, a alternativa é deletar e criar novamente.
Deletando a atual:
[grid@fppserver ~]$ rhpctl delete credentials -cred dibiei_root fppserver.dibiei.com: Audit ID: 239 [grid@fppserver ~]$
Criando uma nova com o mesmo nome:
[grid@fppserver ~]$ rhpctl add credentials -cred dibiei_root -root Enter user "root" password: fppserver.dibiei.com: Audit ID: 240
Considerações de Segurança
Credencial Nomeada
Dentre as 3 opções apresentadas neste post, a que considero mais segura e que mais recomendo é o uso de credencial nomeada. Nesta abordagem, podemos manter a senha do usuário com privilégios administrativos no cofre do FPP, sem que ela seja exposta ou compartilhada por outros usuários.
Um operador do FPP pode realizar praticamente todas as operações fazendo referência a uma credencial já existe no ambiente, sem necessariamente ter acesso a senha da mesma, garantindo uma espécie de uso de propósito específico, não sendo possível este usuário se aproveitar da senha para se conectar no servidor via SSH.
Um exemplo de caso de uso é em ambientes em que o DBA não tem permissão para executar comandos como root, sendo necessário envolver o time de administração de sistema operacional para executar comandos sob situações específicas. Neste tipo de ambiente também é comum que algumas operações sejam permitidas via privilégio sudo, mas limitando especificamente quais comandos podem ser executados. Em um cenário de aplicação de patch Out-Of-Place utilizado pelo FPP, rotineiramente o servidor de banco muda de Oracle Home, e pode ser inviável manter esse tipo de controle individualizado.
Uma alternativa para este requisito de segurança, seria a criação de um usuário de serviço dedicado para o FPP no servidores de banco de dados, e do lado de FPP Server criar uma credencial nomeada em conjunto com o time responsável pela administração do SO, para digitar a senha durante o momento de criação. Desta forma, o DBA ou operador do FPP não teria conhecimento da senha do “super usuário”, mas o FPP poderia executar todas as suas operações se autenticando com o usuário de serviço.
Chave SSH
Depois da opção de credencial nomeada, a que apresenta melhor segurança é a de chave SSH armazenada no FPP Server. Apesar de não oferecer o mesmo nível de segurança da credencial nomeada, ainda é uma solução melhor do que o uso por autenticação por senha, pois já evita o cenário de ter a senha exposta principalmente em uso com REST API.
Para este caso de uso com REST API, a única informação que apareceria no JSON Body seria o caminho onde a chave SSH está localizada dentro do FPP Server, mas não o conteúdo da chave em si. Desta forma, a segurança é condicionada a quem pode acessar o servidor o servidor do FPP direramente.
Autenticação por Senha
Use a opção de autenticação por senha apenas para casos pontuais, testes AD-HOC e algum cenário de teste. Para ambiente produtivo, para ter melhor escalabilidade e integração com outras automações, seja via linha de comando, ou via REST API, opte por usar credencial nomeada ou chave SSH.
Oracle RAC com RHP Client
Por fim, é importante lembrar que essas opções são direcionadas para FPP Targets não gerenciados, que são os servidores de banco single com ou sem Grid Infrastructure, onde o FPP os classifica como ORACLERESTART ou STANDALONE, respectivamente.
Para os FPP Targets gerenciados, aqueles que são Oracle RAC e com RHP Client previamente configurado, a comunicação e autenticação é realizada automaticamente entre o FPP Server e o FPP Client após a configuração inicial, não sendo necessário (nem possível) especificar uma senha, chave SSH ou credencial durante as operações do FPP.