Skip to main content

​
Overview

Understand how Glean establishes secure, least‑privilege access to your AWS account through IAM roles, distinguishing trust policies that determine who can assume a role from permissions policies to what that role can do. Learn about the CloudFormation bootstrap resources and the managed deployment pipeline deploy_build Lambda → CodeBuild which uses Terraform and targeted automation to provision and update your tenant with auditability. Use this information to prepare your environment efficiently, satisfy security reviews, and resolve access‑related questions during rollout and operations. All bootstrapping resources are created through Glean CloudFormation bootstrap template.
  • The bootstrap template contains the authoritative definitions of roles and policies created during initialization. You must notify Glean to begin the build after deploying the template in the selected region.
  • The CloudFormation Template (CFT) only creates the minimal amount of resources needed to get access into the account and start the deployment.

​
Access roles assumed by Glean

Glean uses IAM role–based access for a limited, well‑defined set of actions. Glean does not make use of static IAM access keys. The bootstrap template creates the following roles:
RoleWho assumes itPrimary purpose
glean-deployerGlean central infra through Google‑based web identityInvoke deployment workflows like setup and upgrades, read ELB/ACM metadata to finalize DNS/ACM, set a one‑time bootstrap secret for auth hand‑off.
glean-viewerGlean engineers through AWS Console role‑switch from a known Glean accountRead‑only views for debugging the EC2, ELB, CloudWatch, AutoScaling, VPC, Lambda, EKS and logs.
cron-helper-invokerGlean service account (web identity)Invoke a specific cron_helper Lambda for orchestrated workflows, for example, ML jobs.

​
glean-deployer role

Trust policy: Federated web identity to a known Glean GCP service account (Google OIDC) with a specific OAuth 2 Client ID audience. Specifically, this only allows the service account of Glean’s GCP automation to assume the role. 
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "accounts.google.com" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "102499298255048943192"
        }
      }
    }
  ]
}
Key permissions scope:
  • Invoke a single deployment Lambda (deploy_build) to run setup or upgrade operations.
  • Describe ALB or Listeners or the ListenerCertificates used to finalize DNS CNAME from name-of-instance-be.glean.com → customer ELB.
  • List or describe ACM certificates for DNS validation during cert provisioning.
  • Put a one‑time bootstrap secret value ipjc_auth_token in Secrets Manager for secure control‑plane handshake.

​
glean-viewer role

Trust policy: Assumable from a known Glean AWS account for console‑based, time‑bound debugging. 
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::518642952506:root" },
      "Action": "sts:AssumeRole"
    }
  ]
}
Effective access: Read‑only visibility across EC2 or ELB or CloudWatch or AutoScaling or VPC, Lambda, EKS, CloudWatch Logs (scrubbed), metrics, and dashboards through a minimal set of AWS‑managed policies and tailored Lambda or EKS or Logs viewers. It does not grant access to any data and is only used to view configuration details.

​
cron-helper-invoker role

Trust policy: Federated Google OIDC for a designated service account in Glean’s central GCP project. This is scoped to permit Glean’s CI/CD automation to invoke the cron_helper Lambda only; no other access is provided. 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "accounts.google.com" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "108067902309312661827"
        }
      }
    }
  ]
}

​
Deployment process

To set up infrastructure and perform updates, the account hosts a deploy_build Lambda that launches AWS CodeBuild projects to run Glean’s deployment code. This code is primarily Terraform plus targeted Python for steps that IaC cannot easily handle. The deploy_build execution role named deploy-build has a trust policy for lambda.amazonaws.com and narrow permissions to read config and create or drive CodeBuild, including iam:PassRole limited to a CodeBuild role. Each CodeBuild build runs under the codebuild IAM role, which has broad but deployment‑specific permissions required to create and configure EKS, EC2/VPC networking, KMS, RDS, S3, SQS/SNS, WAFv2, CloudWatch/Logs, ECR, Lambda, IAM constructs, and more needed to bring up the full tenant stack. Full policy statements are defined in the bootstrap template and are applied by Glean’s automated pipelines.

​
Customer controls

  • S3 public access prevention: Glean respects the AWS Block Public Access posture and customers commonly enforce this globally.
  • The Admin Service Role: Glean recommends to create auditable admin service role for rare escalation needs. You can disable all access to this role with an SCP and permit access only when required.
  • For AWS, use KMS Customer Managed Keys (CMK). You own and control the cryptographic keys used to encrypt your data at rest.
  • For information on supported WAF controls and networking, see:
⌘I