‍

Access we need

‍

AWS: Overmind requires read only access to your AWS accounts. This is achieved using an IAM role that uses the “AWS Account” trusted entity type along with an external ID to allow Overmind to read from the required AWS APIs.

The required permissions are documented here: https://github.com/overmindtech/aws-source#required-permissions

‍

Kubernetes: Overmind needs “Get”, “List” and “Watch” permissions for all resources in a cluster. This is configured automatically using a ClusterRole. These permissions are then applied via ServiceAccount to the Overmind agent which runs anywhere in the cluster.

If required Overmind can be configured with fewer permissions on an account-by-account or cluster-by-cluster basis, but this will limit functionality.

‍

Data

‍‍

What we gather:

AWS: The output of the “Get” or “Describe” API action for each supported type e.g. https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html#examples 

Kubernetes: The details of all kubernetes objects. This is the same data that would be returned from “kubectl get {object}”

‍

What we do with it

Overmind is purely graph based. We don’t need to scan your infrastructure and store it in a database. Our data gathering is done on-demand.

‍

The obvious things we store are:

Snapshots of your infrastructure that you create (items and their attributes) so that we can show you what changed.

The definitions of apps that you create:

• User details, configuration etc.

• We do however store one thing other than the obvious: A cache of the last-discovered topology of your infrastructure. It includes the names and relationships of all items, but not the actual attributes.

How long we hold them:

• Topology cache: 1 week
• Snapshots of changes: Until you delete them

All other data: While you’re a customer (or design partner)

‍

Isolation

‍

We’re ops people at heart, we care about things being architected and run properly. To that end Overmind employs a partial isolation model to protect against attacks. Some infrastructure is shared, but each “source” (the part of Overmind that can access your AWS) is run in an isolated environment (a container) with per-customer partitioning at the AWS, application and messaging layer.