Access Requirements

What are Panoptica's access requirements?

Required Access

AWS – Cross-Account Role (including MFA) with read-only policies attached (SecurityAudit, OrganizationReadOnlyAccess, ViewOnlyAccess, and Extended AuditPermissions) – this is used to read the configuration and posture of the AWS Accounts.

Azure – Application with Reader Role attached. This is also a read-only managed role used to read the configuration and posture of the Azure Subscriptions.

Kubernetes – A service account used by our pods with Get/List permissions to the cluster configuration besides secrets.

Data Access

Panoptica collects and analyzes only metadata, meaning the configuration of the assets, network, and identity in the different cloud service providers or Kubernetes. Panoptica does not collect data stored in databases, data storage, etc.

AWS Required Permissions

Security Audit

• A managed policy by AWS dedicated for auditing AWS accounts. The IAM actions are predefined by AWS and have read-only access (https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/SecurityAudit)

AWS Organization Read-only Access

• A managed policy by AWS dedicated to getting the organization tree and service control policies used in the different OU’s and Accounts
  * AWSOrganizationsReadOnlyAccess

ViewOnlyAccess

• A managed policy by AWS dedicated to list and view a list of AWS resources and basic metadata in the account across all services.
  (https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/ViewOnlyAccess)

Panoptica Extended Audit Permissions

• A custom policy by Panoptica to allow our platform to get additional metadata and basic configuration for services not covered in the other managed policies.

CVE Scanning

• We take snapshots of all EC2 Instances in the organization’s account

• We tag each snapshot with the “panoptica” tag and modify the snapshots’ permission to our account

• If the EBS is encrypted, we then grant ourselves the ability to decrypt it (for this reason we have the KMS actions in the policy. Other vendors in the market that have this feature are doing this using full KMS access – we are using the minimal and most secure way we can with create grant and revoke grant permissions).

• Once the snapshot copy is finished, we convert them to a volume and attach them to an on-demand created EC2 instance with our code that scans the volumes in our account

• The results are sent to our platform’s backend, and the snapshots and EC2 instances on demand are terminated

• We delete the snapshots with our tag only. This is what the policy allows.

• The scanning is triggered when the account scan is triggered.