A library catalog function must list objects in an Object Storage bucket at runtime without embedding long-lived user API keys in configuration. What is the correct authentication approach for the running function?
Select an answer to reveal the explanation.
Short Explanation
The running function should show its own badge—its resource principal—not borrow a clerk’s permanent keys from a drawer. Pair that identity with a dynamic group for fnfunc and grant only what the handler needs.
Full Explanation
At runtime, an Oracle Function authenticates to OCI APIs using its resource principal. The platform exposes OCI_RESOURCE_PRINCIPAL_* environment material so the OCI SDK can sign calls as the function itself. Pair that identity with a dynamic group whose matching rule includes fnfunc resources, then grant that group the least-privilege Object Storage permissions the library catalog handler needs to list bucket objects—no long-lived user API keys in configuration.
Storing a tenancy admin user’s PEM key in function config creates a high-blast-radius secret that must be rotated and that violates least privilege even if monthly rotation is attempted. Docker registry auth tokens authenticate to OCIR for image pull concerns; they are not the correct OCI SDK signer for Object Storage data-plane calls from the handler. Disabling IAM and allowing anonymous Object Storage reads from the subnet is neither secure nor the supported Functions identity pattern.
Exam caveat: resource principals still need correct dynamic group matching and IAM policy statements; missing either yields authorization failures that look like “SDK misconfiguration.” Operational check: confirm OCI_RESOURCE_PRINCIPAL_* is present in the runtime, validate the dynamic group matches the function, test list-objects with a minimal policy, and ensure no user PEM or API key appears in application/function configuration.