Configuring Instances for Calling Services
A Compute Cloud@Customer compute instance can be configured to enable applications running on the instance to call services and manage resources similar to the way Compute Cloud@Customer users call services to manage resources.
The IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources is called an instance principal.
Perform the following steps to set up and use an instance as a principal:
-
Configure the instance firewall to enable the instance to access service endpoints. See Configure Instance Firewalls to Allow Calling Services
-
Ensure the instance is included in a dynamic group (configured in your tenancy) that grants permissions to access the required resources. See Managing Dynamic Groups.
The instance must be created in or moved to a compartment that's named in a matching rule of the dynamic group, or the instance must have a resource tag assigned that's named in a matching rule. See Writing Matching Rules to Define Dynamic Groups.
- Enable instance principal authorization for the Java SDK, Python SDK, CLI, or Terraform. See Configuring the SDK, CLI, or Terraform.
Configure Instance Firewalls to Allow Calling Services
As a privileged user, modify the instance firewall configuration to enable the
instance to contact endpoints such as iaas
and
identity
.
-
Save the updated IP tables configuration.
iptables-save > /etc/sysconfig/iptables.rules
-
Create the script
/sbin/restore-iptables.sh
.#!/bin/sh /sbin/iptables-restore < /etc/sysconfig/iptables.rules
-
Set the executable bit on the script.
chmod +x /sbin/restore-iptables.sh
-
Create the file
/etc/systemd/system/restore-iptables.service
with the following content.[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
-
Reload
systemd
manager configuration.systemctl daemon-reload
-
Enable the service.
systemctl enable restore-iptables
Configure Instance Certificates to Allow Calling Services
By default, endpoints (such as iaas
and identity
)
offer a certificate that's signed by a CA that's specific to that Compute Cloud@Customer. By default, OSs don't trust certificates that
are signed by a CA that's specific to this Compute Cloud@Customer. If
the OS doesn't trust the certificates that are offered, attempts to use the OCI SDK
or CLI fail with a CERTIFICATE_VERIFY_FAILED
error.
Implement one of the solutions described in this topic to successfully use the CI SDK or CLI on the instance.
Any user who can SSH to the instance automatically inherits the privileges granted to the instance. Before you grant permissions to an instance, ensure that you know who can access it, and that they should be authorized with the permissions you're granting to the instance.
Option 1: Specify in the SDK Code the CA Bundle to Use
This method copies the appliance-specific CA bundle to the instance, but doesn't
verify the server's certificate (--insecure
). To ensure
security, verify the content of the retrieved bundle
(external_ca.crt
).
-
Retrieve the certificate from the
iaas
endpoint of Compute Cloud@Customer.curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
This command could be in a script that's passed to the instance at launch time by using either the
--user-data-file
option or the--metadata
option with auser_data
field. The script runs bycloud-init
inside the instance during init, saving the effort of manually retrieving this certificate file on many instances. -
Verify the content of the CA bundle saved in the
external_ca.crt
file. -
Specify the CA bundle in the Python SDK code.
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"
Option 2: Globally Trust the Oracle Compute Cloud@Customer CA Bundle
This method is the same as the preceding method with the following difference: Instead of specifying the CA bundle in the SDK code, this method adds the CA bundle to the trust chain.
When the CA bundle is added to the trust chain, every application on this compute instance will trust certificates signed with the CA specified in this bundle. Consider whether this is an acceptable security risk.
-
Retrieve the certificate from the
iaas
endpoint of Compute Cloud@Customer.curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
-
Verify the content of the CA bundle saved in the
external_ca.crt
file. -
Update the global CA trust chain.
cp external_ca.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust extract