Pulumi Insights: Before You Begin

To configure Pulumi Insights with AWS, you will use OpenID Connect (OIDC) for authentication. Follow these steps:

1. Log in to the AWS Management Console.
2. Go to the Roles section and create a new role.
3. Select the Web identity trusted entity type and choose api.pulumi.com/oidc as your identity provider.
4. Select the name of your Pulumi organization under Audience.
5. Filter to the ReadOnlyAccess policy name.
6. Click Create.

This will set up a trust relationship to allow Pulumi Cloud to assume the role using the following trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Principal": {
                "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/api.pulumi.com/oidc"
            },
            "Condition": {
                "StringEquals": {
                    "api.pulumi.com/oidc:aud": "aws:<ORG_NAME>"
                }
            }
        }
    ]
}

For a more detailed step-by-step guide, including screenshots see the Configuring OpenID Connect for AWS Pulumi documentation.

Next, go back to Pulumi ESC and configure your cloud credentials using the role ARN and trust relationship you just created:

values:
  aws:
    login:
      fn::open::aws-login:
        oidc:
          duration: 1h
          roleArn: arn:aws:iam::<YOUR_AWS_IAM_ID>:role/insights-discovery-1
          sessionName: esc-${context.pulumi.user.login}
  environmentVariables:
    AWS_ACCESS_KEY_ID: ${aws.login.accessKeyId}
    AWS_SECRET_ACCESS_KEY: ${aws.login.secretAccessKey}
    AWS_SESSION_TOKEN: ${aws.login.sessionToken}

To configure Pulumi Insights with Azure, you can use either OpenID Connect (OIDC) or client secret authentication. We recommend using OIDC for passwordless authentication, as it is more secure and eliminates the need to store and manage long-lived credentials.

Option 1: OIDC authentication (recommended)

1. Create a Microsoft Entra application and configure federated credentials
2. Assign the appropriate role to your service principal (e.g., Reader role for read-only access)
3. Configure your ESC environment with OIDC settings

Example ESC configuration for OIDC:

values:
  azure:
    login:
      fn::open::azure-login:
        clientId: <YOUR_CLIENT_ID>
        tenantId: <YOUR_TENANT_ID>
        subscriptionId: <YOUR_SUBSCRIPTION_ID>
        oidc: true
  environmentVariables:
    ARM_USE_OIDC: 'true'
    ARM_CLIENT_ID: ${azure.login.clientId}
    ARM_TENANT_ID: ${azure.login.tenantId}
    ARM_OIDC_TOKEN: ${azure.login.oidc.token}
    ARM_SUBSCRIPTION_ID: ${azure.login.subscriptionId}

Option 2: Client secret authentication

Alternatively, you can use a Service Principal with a client secret. This requires generating a client secret in Azure and storing it securely in ESC.

To configure Pulumi Insights with OCI, you will use OpenID Connect (OIDC) for authentication.

1. Set up API Key authentication by providing the following credentials:

• OCI_TENANCY_OCID: OCID of the tenancy. To get the value, see Where to Get the Tenancy’s OCID and User’s OCID.
• OCI_USER_OCID: The OCID of the user calling the API. See Where to Get the Tenancy’s OCID and User’s OCID.
• OCI_PRIVATE_KEY_PASSWORD: (Optional) Passphrase used for the key, if it’s encrypted.
• OCI_FINGERPRINT: Fingerprint for the key pair being used. See How to Get the Key’s Fingerprint.
• OCI_REGION: The OCI region where your resources are located. See Regions and Availability Domains.
• OCI_PRIVATE_KEY_PATH: The private key is required to be listed as an ESC file. To create a private key and integrate it with ESC, see How to Generate an API Signing Key and how to upload the public key

Next, go back to Pulumi ESC and configure your cloud credentials and trust relationship you just created:

values:
  environmentVariables:
    OCI_FINGERPRINT: "25:ad:34:****************:cd:05:05:08:02:a7"
    OCI_REGION: "us-phoenix-1"
    OCI_TENANCY_OCID: "ocid1.tenancy.oc1..tenancyidnumbers"
    OCI_USER_OCID: "user_ocid"
  files:
    OCI_PRIVATE_KEY_PATH: "<PRIVATE_KEY_CONTENT>"

By default, the Kubernetes scanner uses kubeconfig for authentication. You can provide the contents of the kubeconfig file using a file-based environment variable. The authenticated user must have get and list permissions at the cluster scope to discover all resources.

An example ESC configuration would look like:

values:
  files:
    KUBECONFIG: <INSERT_KUBECONFIG_CONTENTS>  # Provide the kubeconfig contents here

This configuration projects the kubeconfig file contents to a temporary file that the ESC scanner uses for authentication.

For a detailed guide on configuring ESC credentials for Insights with Kubernetes see the following documentation.