Start Screening with the Granica Platform

The easiest way to get started with Screen is via the Granica Platform. This guide covers the process of deploying the platform and kicking off your first scan. Let's do it!

Create a dedicated AWS Account

First, Create an account within your AWS Organization using the AWS Organizations console. This is the account into which you'll deploy Granica .

The account creation process will automatically create an administrator role for the new account. This role will give Granica the ability to create the required resources for the platform.

After account creation, you will need AWS CLI access to assume this role. If you don't already have the AWS CLI installed, follow AWS installation instructions to install it on your machine. Add the account and role as a new profile in your AWS CLI config file located at $HOME/.aws/config.

We recommend using granica as the profile name.

[profile granica]
role_arn = arn:aws:iam::<account-number>:role/<role name given during account-creation>
source_profile = default

Your source_profile must have permissions to assume the administrator role of the new account.

Deploy Granica Platform via Terraform

First, contact us to coordinate a deployment time as, at present, each deployment requires real-time approval by our team. We will also provide you with a package URL.

From your local machine or VM, download the script, which automates deployment and configuration of Screen, from the pane to the right. Grant execution permissions to the script and run it.

chmod +x
./ --package <url>

Deployment customization

All configuration values are automatically stored in the terraform.tfvars file using the options below:

  • Profile: The AWS CLI profile to use.
  • Region: The AWS region which will contain the Granica resources.
  • SSH access CIDRs: CIDR range from which SSH access to the Granica Admin Server is permitted. If not specified, access is not restricted.
  • SSH key name: The name of an existing AWS key pair to use with the Admin Server. If not specified, a new key pair is created.

Common Setup Config Inputs

You will be prompted to either confirm or provide/update a few configuration details, including the AWS profile to use. Your specified AWS profile must represent the IAM role you created earlier. The deployment region is also inherited from this profile and must be where the buckets for which you wish to estimate savings are located. See below for an example.

./ --package <url>
Use the AWS CLI profile 'default'? (Y/N) N
Enter desired AWS CLI profile: <sub-account-profile>
Allow SSH access to the Admin Server from all CIDRs? (Y/N) N
Enter CIDR range to restrict SSH access to (in the format ["a", "b", ...]): [""]
Deploy a new cluster? (Y/N) Y
Generate a new key pair to use with the Admin Server (recommended)? (Y/N) Y
Tag generated resources with your AWS ARN? (Y/N) Y

You can run ./ --package <url> --manual-confirm to inspect the resource creation plan before applying it. Additionally, the terraform files are wrapped inside the rpm install file, sSo once the rpm is installed on your Granica Admin Server you can inspect the files manually.


What is the setup process doing?

The setup script provisions an Admin Server (the Granica control plane). It then logs in to this new Admin Server and deploys a self-managed Kubernetes cluster, which is the Granica data plane. The minimum set of permissions for Granica roles to create and access Granica-internal resources are granted by the administrator user via the deploy process, automatically.

If you have deployed Granica from this machine or VM before, you will be prompted to provide a local identifier for this new deployment. This identifier is used locally only to maintain the state for the Admin Server instances that manage each deployment.

Grant read-only access to your S3 buckets

Role-based permissions for Screen to access your S3 source buckets are handled via Amazon S3 cross account bucket policies. For each S3 bucket for which you would like to screen, add a statement like the following to the list of statements in the policy for that bucket.

Update the <bucket-name> with the name of your bucket.

Update the AWS principal with the Granica principal.

How can I obtain the Granica Principal?

From your Granica Admin Server run the following command to obtain the principal for the Granica data-cruncher role.

terraform -chdir=$HOME/.project-n/aws/default/infrastructure/ output aws_data_cruncher_role_arn

The Granica data cruncher role will be in the following form:

"Sid": "Read-Only Access for Granica Screen",
"Principal": {
"AWS": "arn:aws:iam::<dedicated-account-id>:role/<cluster-id>-data-cruncher"
"Effect": "Allow",
"Action": ["s3:Get*", "s3:List*", "s3:PutBucketNotification"],
"Resource": ["arn:aws:s3:::<bucket-name>", "arn:aws:s3:::<bucket-name>/*"]

Screen sample data

Run the following command to start screening objects in your specified bucket(s).

granica execute-policy

You can use granica policy edit in combination with granica execute-policy to limit screening to specific objects via object-include and object-exclude filters.


Grant read access for Granica via S3 bucket policy permissions and then run the granica policy execute command on those buckets. If you would like to try out Screen with publicly available buckets, first configure your AWS environment for public access.

View dashboard

Run the following command to retrieve the URL and credentials for your Screen dashboard. Then, log in to view your advanced PII detection metrics.

granica dashboard

The dedicated account deployment model isolates Granica resources from your production environment and accounts. This makes it risk-free not just in evaluation mode, but also in production mode.