Configurando Instâncias para Serviços de Chamada

Modificar a Configuração de Firewall

Como usuário privilegiado, modifique a configuração do firewall da instância para permitir que a instância acesse pontos finais de serviço, como iaas e identity.

Use o comando iptables para adicionar as seguintes regras do BareMetalInstanceServices ao firewall de instância:

iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.169.254 --dport 443 -j ACCEPT
iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.240.254 --dport 443 -j ACCEPT

A primeira entrada é obrigatória para todos os pontos finais. A segunda entrada é necessária para entrar em contato com o ponto final do Object Storage.

Tornar as Alterações de Configuração Persistentes

Use o procedimento a seguir para fazer com que essas alterações de configuração do firewall persistam nas reinicializações da instância.

1. Salve a configuração atualizada das tabelas IP.

   iptables-save > /etc/sysconfig/iptables.rules

2. Criar um script para restaurar automaticamente a configuração atual do firewall (modificado) na reinicialização.

   Neste exemplo, o script é chamado /sbin/restore-iptables.sh. Este é o conteúdo do arquivo /sbin/restore-iptables.sh:

   #!/bin/sh
   /sbin/iptables-restore < /etc/sysconfig/iptables.rules

3. Defina o bit executável no script.

   chmod +x /sbin/restore-iptables.sh

4. Crie um serviço systemd oneshot para executar o script /sbin/restore-iptables.sh no momento da inicialização.

   Neste exemplo, o serviço é chamado /etc/systemd/system/restore-iptables.service. Este é o conteúdo do arquivo /etc/systemd/system/restore-iptables.service:

   [Unit]
   Description=Restore IP Tables
   After=cloud-final.service
   
   [Service]
   ExecStart=/sbin/restore-iptables.sh
   User=root
   Group=root
   Type=oneshot
   
   [Install]
   WantedBy=multi-user.target

5. Recarregue a configuração do gerenciador systemd e ative o serviço a ser executado no momento da inicialização.

   systemctl daemon-reload
   systemctl enable restore-iptables

Opção 1: BYOC (Bring Your Own Certificate)

Se você tiver um certificado assinado por uma CA na qual seu sistema operacional confia, configure o Roving Edge para oferecer esse certificado.

Em um sistema operacional Linux, o seguinte comando lista CAs confiáveis por padrão:

trust list --filter=ca-anchors

Para obter informações sobre como fornecer seu próprio certificado, consulte "Accessing External Interfaces with Your CA Trust Chain".

Opção 2: Especificar no Código SDK o Pacote de CAs a Ser Usado

Esse método copia o bundle de CAs específico do appliance para a instância, mas não verifica o certificado do servidor (--insecure). Para garantir a segurança, verifique o conteúdo do pacote recuperado (external_ca.crt).

1. Recupere o certificado do ponto final iaas do appliance.

   curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain

   Esse comando pode estar em um script que é passado para a instância no momento da inicialização usando a opção --user-data-file ou a opção --metadata com um campo user_data. O script será executado por cloud-init dentro da instância durante a inicialização, salvando o esforço de recuperar manualmente esse arquivo de certificado em um grande número de instâncias.

2. Verifique o conteúdo do bundle de CAs salvo no arquivo external_ca.crt.

3. Especifique o bundle de CAs no código SDK do Python.

   signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner(
       federation_client_cert_bundle_verify="/home/opc/external_ca.crt"
   )
   identity_client = oci.identity.IdentityClient(config={}, signer=signer)
   identity_client.base_client.session.verify = "/home/opc/external_ca.crt"

Opção 3: Confiar Globalmente no Pacote de CAs do Roving Edge

Esse método é igual ao método anterior com a seguinte diferença: em vez de especificar o bundle de CAs no código do SDK, esse método adiciona o bundle de CAs à cadeia de confiança.

1. Recupere o certificado do ponto final iaas do appliance.

   curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain

2. Verifique o conteúdo do bundle de CAs salvo no arquivo external_ca.crt.

3. Atualize a cadeia de confiabilidade global da CA.

   cp external_ca.crt /etc/pki/ca-trust/source/anchors/
   update-ca-trust extract

As etapas 1 e 3 desse método podem estar em um script que é passado para a instância no momento da inicialização usando a opção --user-data-file ou a opção --metadata com um campo user_data. O script será executado pelo cloud-init dentro da instância durante a inicialização, poupando o esforço de executar essas etapas manualmente em um grande número de instâncias.

Ativando a Autorização do Controlador de Instâncias para o Python SDK

No SDK para Python, crie um objeto oci.auth.signers.InstancePrincipalsSecurityTokenSigner conforme mostrado no seguinte exemplo:

# By default this will hit the auth service in the region returned by http://169.254.169.254/opc/v1/instance/region on the instance.
			
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
identity_client = oci.identity.IdentityClient(config={}, signer=signer)

Para atualizar o token sem aguardar, use o seguinte comando:

signer.refresh_security_token()

Ativando a Autorização Principal da Instância para a CLI

Defina a opção de autorização (--auth) para um comando, conforme mostrado no seguinte exemplo:

oci os ns get --auth instance_principal

Como alternativa, defina a seguinte variável de ambiente:

OCI_CLI_AUTH=instance_principal

Se ambos forem definidos, o valor definido para --auth terá precedência sobre a variável de ambiente.

Ativando a Autorização Principal da Instância para o Terraform

Defina o atributo auth como "InstancePrincipal" na definição do provedor, conforme mostrado no seguinte exemplo:

variable "region" {}

provider "oci" {
   auth = "InstancePrincipal"  
   region = "${var.region}"

}

Quando você usa a autorização do controlador de instâncias, não precisa incluir os atributos tenancy_ocid, user_ocid, fingerprint e private_key_path.