Skip to main content

Deployment Model​

1SaaS + Agent (Hybrid)

Pros

  • Keeps cloud credentials and secrets within the infrastructure
  • Fits into a GitOps flow
  • Allows reuse of health checks with Flux or Argo

Cons

  • Requires a Kubernetes cluster (e.g., Kind or Microk8s)

See Getting Started

2Self Hosted

Mission Control is designed to be self-hosted first, i.e the functionality available when self-hosting will always have feature parity with the SaaS (And in some cases there is functionality available self-hosted that is not available on the SaaS)

Pros

  • Hosted on your infrastructure (On-Premise, AWS, Google, Azure, etc..)
  • Only dependency is a Postgres DB (bundled into the Helm chart by default)
  • Automatic upgrades using Helm Semantic Versioning

Cons

  • Single Sign-On setup required
  • Postgres database management required

See Self-Hosted

3SaaS Only

The fully hosted deployment model does not require any changes to your infrastructure, but will require connections to be setup and configured on Mission Control to connect to your existing infrastructure and is therefore not recommended for production.

Pros

  • Fastest to set up

Cons

  • Requires public network access to your infrastructure
  • Credentials and secrets are stored in the Flanksource Mission Control Cloud
Non Production Only

While Flanksource takes the necessary steps to protect all credentials saved in our cloud, sharing credentials with third parties is not a recommended security practice. Therefore, we do not recommend the fully hosted option for production environments.

Ingestion Model​

All deployment models can support different way of ingesting data, this is relevant in particular to multi-cluster, multi-account setups.

Hub and Spoke​

With the hub and spoke model, your primary instance (whether that is an agent or SaaS) connects to multiple accounts and clusters

Pros

  • Lower overhead during setup, especially if secrets containing the kubeconfig or other access credentials are already available.

Cons

  • Reduced performance, particularly if clusters are in different regions or have costly authentication processes.
  • Reduced security, as maintaining credentials in one location can facilitate lateral movement by attackers.
  • Inbound network access is required.

Multi-Agent​

In the multi-agent setup an agent is installed in each cluster, and 1 agent per account/region is designated for scraping cloud resources:

Pros

  • High security, agents do not need to have inbound network access, and the use of local RBAC limits their privilege.
  • Increased performance, scraping and watching resources closer to their API endpoints is faster, and with most filtering and transformation being applied by the agent, the scalability of the central instance is improved.
  • Suitable for deployment into customer enviroments by software vendors or managed service providers.

Cons

  • Slightly higher operational overhead