Configuración de Instancias para Llamar a Servicios

Una instancia informática de Roving Edge se puede configurar para permitir que las aplicaciones que se ejecutan en la instancia llamen a servicios y gestionen recursos similares a la forma en que los usuarios de Roving Edge llaman a servicios para gestionar recursos.

Un principal de instancia es una instancia informática que está autorizada para realizar acciones en recursos de servicio. Las aplicaciones que se ejecutan en un principal de instancia pueden llamar a servicios y gestionar recursos similares a la forma en que los usuarios de Oracle Roving Edge llaman a servicios para gestionar recursos. La instancia es un actor principal, al igual que un usuario es un actor principal. Cuando utiliza principales de instancia, no necesita configurar credenciales de usuario ni un archivo de configuración en la instancia para ejecutar aplicaciones que necesiten gestionar recursos de servicio.

Para otorgar autorizaciones a un principal de instancia, incluya la instancia como miembro de un grupo dinámico. Un grupo dinámico proporciona autorizaciones a las instancias, al igual que un grupo de usuarios proporciona autorizaciones a los usuarios.

La función del servicio IAM que permite que las instancias sean actores (o entidades de seguridad) autorizados para realizar acciones en recursos de servicio se denomina entidad de servicio.

Realice los siguientes pasos para configurar y utilizar una instancia como principal:

Configure el firewall de instancia para permitir que la instancia acceda a los puntos finales del servicio. Consulte Configuración de firewalls de instancia para permitir llamadas a servicios.
Asegúrese de que la instancia esté incluida en un grupo dinámico que otorgue permisos para acceder a los recursos necesarios. Consulte Creación y gestión de grupos dinámicos.

La instancia se debe crear o mover a un compartimento con nombre en una regla de coincidencia del grupo dinámico, o bien la instancia debe tener asignada una etiqueta de recurso con nombre en una regla de coincidencia. Consulte Escritura de reglas de confrontación.

Configuración de firewalls de instancia para permitir llamadas a servicios

En este tema se describe cómo modificar la configuración del firewall de instancia y cómo crear un servicio systemd para restaurar los cambios si el sistema se reinicia.

Modificación de la configuración del firewall

Como usuario con privilegios, modifique la configuración del firewall de instancia para permitir que la instancia acceda a puntos finales de servicio como iaas y identity.

Utilice el comando iptables para agregar las siguientes reglas BareMetalInstanceServices al firewall de instancia:

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

La primera entrada es necesaria para todos los puntos finales. La segunda entrada es necesaria para ponerse en contacto con el punto final de Object Storage.

Persistencia de los Cambios de Configuración

Utilice el siguiente procedimiento para que estos cambios de configuración de firewall se mantengan tras los reinicios de la instancia.

Guarde la configuración actualizada de las tablas IP.
```
iptables-save > /etc/sysconfig/iptables.rules
```
Cree una secuencia de comandos para restaurar automáticamente la configuración de firewall actual (modificada) al reiniciar.

En este ejemplo, el script se denomina /sbin/restore-iptables.sh. A continuación se muestra el contenido del archivo /sbin/restore-iptables.sh:
```
#!/bin/sh
/sbin/iptables-restore < /etc/sysconfig/iptables.rules
```
Defina el bit ejecutable en el script.
```
chmod +x /sbin/restore-iptables.sh
```
Cree un servicio systemd oneshot para ejecutar la secuencia de comandos /sbin/restore-iptables.sh en el momento del inicio.

En este ejemplo, el servicio se denomina /etc/systemd/system/restore-iptables.service. A continuación se muestra el contenido del archivo /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
```
Vuelva a cargar la configuración del gestor systemd y active el servicio para que se ejecute en el momento del inicio.
```
systemctl daemon-reload
systemctl enable restore-iptables
```

Configuración de Certificados de Instancia para Permitir Llamadas a Servicios

Por defecto, los puntos finales de Roving Edge (como iaas y identity) ofrecen un certificado firmado por una CA que es específica de ese dispositivo. Por defecto, los sistemas operativos no confían en los certificados firmados por una CA que es específica de este Roving Edge. Si el sistema operativo no confía en los certificados que se ofrecen, los intentos de utilizar el SDK o la CLI de OCI fallarán con un error CERTIFICATE_VERIFY_FAILED.

Implante una de las soluciones descritas en este tema para utilizar correctamente el SDK o la CLI de OCI en la instancia.

Nota

Cualquier usuario que pueda acceder a la instancia mediante SSH hereda automáticamente los privilegios otorgados a la instancia.

Opción 1: Traiga su propio cheque regalo (BYOC)

Si tiene un certificado firmado por una autoridad de certificación en el que confía su sistema operativo, configure Roving Edge para ofrecer ese certificado.

En un sistema operativo Linux, el siguiente comando muestra las CA que son de confianza por defecto:

trust list --filter=ca-anchors

Para obtener información sobre cómo proporcionar su propio certificado, consulte "Acceso a interfaces externas con su cadena de confianza de CA".

Opción 2: Especificar en el código SDK el paquete de CA que se va a utilizar

Este método copia el grupo de autoridades de certificación específicas del dispositivo en la instancia, pero no verifica el certificado del servidor (--insecure). Para garantizar la seguridad, verifique el contenido del paquete recuperado (external_ca.crt).

Recupere el certificado del punto final iaas del dispositivo.
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_name.domain_name/cachain
```
Este comando puede estar en un script que se transfiere a la instancia en el momento del inicio mediante la opción --user-data-file o la opción --metadata con un campo user_data. El script lo ejecutará cloud-init dentro de la instancia durante la inicialización, lo que ahorrará el esfuerzo de recuperar manualmente este archivo de certificado en un gran número de instancias.
Verifique el contenido del grupo de CA guardado en el archivo external_ca.crt.

Especifique el grupo de autoridades de certificación en el código SDK de 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"

Opción 3: Confiar Globalmente en el Grupo de CA Roving Edge

Este método es el mismo que el método anterior con la siguiente diferencia: en lugar de especificar el grupo de CA en el código SDK, este método agrega el grupo de CA a la cadena de confianza.

Nota

Cuando el grupo de autoridades de certificación se agrega a la cadena de confianza, todas las aplicaciones de esta instancia informática confiarán en los certificados firmados con la autoridad de certificación especificada en este grupo. Considere si se trata de un riesgo de seguridad aceptable.

Recupere el certificado del punto final iaas del dispositivo.

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

Verifique el contenido del grupo de CA guardado en el archivo external_ca.crt.

Actualice la cadena de confianza de CA global.

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

Los pasos 1 y 3 de este método pueden estar en un script que se transfiere a la instancia en el momento del inicio mediante la opción --user-data-file o la opción --metadata con un campo user_data. El script lo ejecutará cloud-init dentro de la instancia durante init, lo que ahorrará el esfuerzo de realizar estos pasos manualmente en un gran número de instancias.

Configuración del SDK y la CLI de Python para principales de instancias

En este tema se describe cómo activar la autorización de principal de instancia para el SDK de Python, la CLI o Terraform.

Activación de la autorización de principal de instancia para el SDK de Python

En el SDK para Python, cree un objeto oci.auth.signers.InstancePrincipalsSecurityTokenSigner como se muestra en el siguiente ejemplo:

# 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 refrescar el token sin esperar, utilice el siguiente comando:

signer.refresh_security_token()

Permitir autorización de principal de instancia para la CLI

Defina la opción de autorización (--auth) para un comando como se muestra en el siguiente ejemplo:

oci os ns get --auth instance_principal

También puede definir la siguiente variable de entorno:

OCI_CLI_AUTH=instance_principal

Si se especifican ambas, el valor establecido para --auth tiene prioridad sobre la variable de entorno.

Permitir autorización de principal de instancia para Terraform

Defina el atributo auth como "InstancePrincipal" en la definición del proveedor, como se indica en el siguiente ejemplo.

variable "region" {}

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

}

Al utilizar la autorización del principal, no necesita incluir los atributos tenancy_ocid, user_ocid, fingerprint ni private_key_path.

Documentación de Oracle Cloud Infrastructure