How Outpost Works

Outpost (also called InHost) runs the Relyance scanner in your own AWS account. The scanner reads and classifies data in your account. Relyance gets scan results, not your data.

You deploy Outpost with public, versioned code that you can read before you run it:

#At a glance

1. Apply the Terraform module in your AWS account. It creates two buckets, a KMS key and two IAM roles. It can also create the EKS cluster, or use one that you have.
2. Send the module output to Relyance. Relyance sets up its side and sends you a small kustomize folder with the values for your deployment.
3. Apply the manifests to the cluster with kubectl.
4. Add connections to your data sources, in the Relyance web application or with the Terraform provider.

Relyance never gets access to your cluster, console or network. You run every step with your own tools and credentials. For the full commands, refer to Deployment plan.

#Design principles

#Architecture

Outpost has two parts: the components in your AWS account, and the Relyance platform.

#How a scan works

The numbers match the arrows in the diagram.

1. The cluster pulls the scanner images from the Relyance container registry.
2. Relyance puts a scan command in the command queue. The autoscaler sees the waiting command and starts scanner workers. A scanner worker pulls the command.
3. The scanner gets the connection settings from the control plane API. During the scan, it reports progress and completion to the same API. These reports contain status and counts, not your data.
4. The scanner reads the credentials for the data source from the secret store.
5. The scanner connects to the data source and reads sample data. The sample data stays in your account.
6. The scanner keeps temporary scan data in the work bucket.
7. The scanner classifies the sample data in the cluster and writes the results to the findings bucket.
8. Relyance copies the results from the findings bucket with a read-only identity. The results show in the Relyance web application.

#Deployment plan

#Before you start

#Step 1: Create the AWS resources

Add the module to a Terraform configuration and apply it with your own AWS credentials.

To use an existing EKS cluster:

module "outpost" {
  source  = "Relyance-Ext/sierra/aws"
  version = "0.7.0"

  create_vpc_and_eks        = false
  existing_eks_cluster_name = "my-cluster"

  # The AWS accounts whose IAM roles the scanner can assume to read data sources.
  # Set this, or set assume_all_roles = true.
  assumable_account_ids = ["111122223333"]

  # The manifests deploy into the "inhost" namespace.
  additional_service_account_namespaces = ["inhost"]

  # Optional: secrets for In Host BYOK connections.
  byok_secret_arn_patterns = [
    "arn:aws:secretsmanager:us-west-2:111122223333:secret:relyance/inhost/*",
  ]
}

provider "aws" {
  region = "us-west-2"
  default_tags {
    tags = module.outpost.default_tags
  }
}

output "outpost" {
  description = "Send this output to Relyance"
  value       = module.outpost
}

To create a new EKS cluster, replace the cluster settings with the network ranges for the new VPC:

  create_vpc_and_eks = true
  vpc_cidr           = "172.30.0.0/16"
  service_cidr       = "10.100.0.0/16"
  nat_subnet_cidr    = "172.30.255.0/24"
  subnet_cidrs = {
    usw2-az1 = "172.30.0.0/20"
    usw2-az2 = "172.30.16.0/20"
    usw2-az3 = "172.30.32.0/20"
    usw2-az4 = "172.30.48.0/20"
  }

  # Empty means the cluster API endpoint is private only.
  eks_public_access_cidrs = []

Set one subnet for each availability zone ID in the region. Then run:

terraform init
terraform apply
terraform output -json outpost

For all inputs, refer to the module documentation.

#What the module creates

The module creates its own KMS key. It does not accept an existing key.

#Step 2: Send the output to Relyance

Send the outpost output to your Relyance team. It contains no secrets. Relyance uses these values:

Relyance then sends you a kustomize folder for your deployment. It points at the published manifests, and it adds your values: the Relyance project of your tenant, your bucket names, your region, and the identity settings. It contains no secrets.

#Step 3: Install the cluster components

The manifests are plain YAML files on a public URL. The version is in the path, and each version never changes after it is published.

1. Install KEDA. Skip this step if KEDA is already in the cluster.

   kubectl apply --server-side \
     -f https://assets.relyance.ai/inhost/k8s/v1.1.1/keda-aws-prod-v1.1.1.yaml

2. Create the namespace.

   kubectl create namespace inhost

3. Apply the folder from Relyance.

   kubectl apply -k ./relyance-outpost

The kustomization.yaml in the folder starts like this:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - https://assets.relyance.ai/inhost/k8s/v1.1.1/services-aws-prod-v1.1.1.yaml
patches:
  - path: patch-tenant-values.yaml
    target:
      version: v1
      kind: ConfigMap
      name: common-env
  # ...

To read the manifests before you apply them, download them and check them against the published checksums:

curl -fsSLO https://assets.relyance.ai/inhost/k8s/v1.1.1/services-aws-prod-v1.1.1.yaml
curl -fsSL https://assets.relyance.ai/inhost/k8s/v1.1.1/SHA256SUMS-v1.1.1.txt \
  | shasum -a 256 -c --ignore-missing

#What the manifests install

The services file contains no Role, ClusterRole or CRD, and no monitoring, log or telemetry agent. The KEDA file installs the standard KEDA components, with their own CRDs and cluster roles. The pods run as non-root with all Linux capabilities dropped, and meet the Kubernetes Restricted Pod Security Standard.

#Step 4: Add connections

A connection tells the scanner how to reach one data source. Set its runtime mode to run the scan in Outpost:

New connections start as Relyance-hosted. Set the runtime mode on each Outpost connection. Use In Host BYOK to keep the credentials in your account.

In the web application, follow Store Outpost Credentials in a Customer-Managed Secret.

With Terraform, use the Relyance provider. The provider signs in as a Relyance OAuth client with the Integration Configuration Management role. This example keeps the Jira credentials in AWS Secrets Manager. Only the secret ARN goes to Relyance:

terraform {
  required_providers {
    relyance = {
      source  = "Relyance/relyance"
      version = "~> 1.1"
    }
  }
}

# Set RELYANCE_CLIENT_ID and RELYANCE_CLIENT_SECRET in the environment.
provider "relyance" {}

resource "aws_secretsmanager_secret" "jira" {
  name = "relyance/inhost/jira"
}

resource "aws_secretsmanager_secret_version" "jira" {
  secret_id = aws_secretsmanager_secret.jira.id
  secret_string = jsonencode({
    ORG_ID  = "REPLACE_ME"
    API_KEY = "REPLACE_ME"
  })
  lifecycle {
    ignore_changes = [secret_string]
  }
}

resource "relyance_integration_connection" "jira" {
  vendor       = "atlassian_jira"
  name         = "Jira (Outpost)"
  runtime_mode = "IN_HOST_BYOK"

  auth = {
    method = "api-key"
    params = {
      data_storage_location = "us"
    }
  }

  secret_ref = aws_secretsmanager_secret.jira.arn

  scans = {
    "vendor-discovery" = { enabled = true }
  }

  depends_on = [aws_secretsmanager_secret_version.jira]
}

Put the real credential values in the secret outside Terraform, so that they are not in the Terraform state. The secret ARN must match byok_secret_arn_patterns in the module. For each vendor's fields and methods, refer to the provider documentation.

Authentication methods that need a browser sign-in (OAuth) go through Relyance, so Relyance gets those tokens. These methods cannot use a secret ARN. For the details, refer to Authentication methods that cannot use AWS Secrets Manager.

#Step 5: Check the deployment

Start a scan on a connection in the Relyance web application. While it runs, the scanner pods show in the cluster:

kubectl get scaledjobs,pods -n inhost

The scan status shows in the web application. The results show when the scan completes.

#What Relyance receives

Note. The matched values that the scanner finds are not included in the scan results that Relyance copies.

#Security

Identity. The Outpost components keep no long-lived credentials. The scanner pods get the Relyance_Sierra role through EKS Pod Identity. They sign in to the Relyance command queue and API with short-lived credentials from workload identity federation.

Credentials. With In Host BYOK, the credentials stay in a secret in your account. Relyance stores only the secret ARN and rejects credential values for these connections. The scanner reads the secret during the scan with its own role. For the setup steps, refer to Store Outpost Credentials in a Customer-Managed Secret.

Encryption. All connections to Relyance use TLS. A KMS key in your account encrypts the findings bucket and the work bucket.

Access. Relyance has one read-only role, Relyance_Sierra_Reader. It can read the findings bucket only, and only with the external ID from your module. Relyance has no Kubernetes, console or network access to your environment. When the module creates the cluster, it gives cluster administrator access only to the identity that applies it and to the identities that you list in eks_kubectl_admins.

Network. The cluster makes only outbound connections. The VPC that the module creates has outbound internet access through NAT gateways and no inbound path. To limit outbound traffic, allow these destinations:

#Data retention in your account

Versioning is on for both buckets. The lifecycle rules expire the current version of each object. Earlier versions of an object stay until you delete them, or until you add a lifecycle rule for noncurrent versions.

#Operations and support

Updates. You control three versions:

Monitoring. The deployment sends no logs, metrics or telemetry to Relyance. Logs stay in your cluster. Use your own tools to collect them.

Support. Relyance collects no diagnostic data automatically. Relyance support uses only the diagnostic data that you decide to share.

#Related

• How Relyance AI Works
• Store Outpost Credentials in a Customer-Managed Secret