Security Best Practices

Secure your Apollo GraphOS Operator deployment

This guide provides security best practices for deploying and operating the Apollo GraphOS Operator in production environments. We strongly recommend using the Helm chart as it implements many security best practices by default.

Using the Helm Chart (recommended)

The Apollo GraphOS Operator Helm chart implements several security best practices out of the box:

Service account security

  • Dedicated Service Account: Creates a dedicated apollo-operator ServiceAccount with minimal required permissions

  • Namespace-Scoped RBAC: Supports namespace-scoped deployments to limit operator access to specific namespaces

  • Principle of Least Privilege: Implements granular RBAC rules that grant only necessary permissions for each controller

Manual deployment security considerations

If you cannot use the Helm chart, ensure your manual deployment includes these security measures:

Service account and RBAC

The Apollo GraphOS Operator requires a dedicated ServiceAccount with specific permissions for each resource type:

Required permissions by resource type

Subgraph:

  • Watch, list, and get Subgraph resources

  • Create, update, and patch Subgraph status resources

Supergraph:

  • Watch, list, and get Supergraph resources

  • Create, update, and patch Supergraph status resources

  • Create, update, and patch Deployments, Services, ConfigMaps, and Secrets

  • Watch ReplicaSets and Events

SupergraphSchema:

  • Watch, list, and get SupergraphSchema resources

  • Create, update, and patch SupergraphSchema status resources

SupergraphSet:

  • Watch, list, and get SupergraphSet and Supergraph resources

  • Create, update, and patch SupergraphSet status resources

RBAC configuration

The operator supports both cluster-scoped and namespace-scoped deployments. For production environments, use namespace-scoped mode to limit the operator's access to specific namespaces.

API key security

Apollo GraphOS Operator uses two API keys: an operator API key and a supergraph API key. Both are stored in Kubernetes Secrets and should be secured according to Kubernetes Secrets Good Practices.

Operator API key

The operator uses an organization-scoped Operator API key to publish subgraph schemas, fetch composed supergraph schemas, and manage graph API keys for router deployments. For prerequisites, how to create the key, and which Platform API operations it supports, see Operator API keys.

Supergraph API key

The operator automatically creates and manages a supergraph API key for each Supergraph resource. This is a graph-scoped API key, not org-scoped, that the operator provisions for each Supergraph resource, with the GRAPH_ADMIN role on the specific graph. This role enables the GraphOS Router to emit usage metrics for protected graph variants.

The operator creates a supergraph API key when a Supergraph resource is created, using the name pattern operator-<random> to distinguish multiple keys. It then stores the key in a Kubernetes Opaque Secret with an APOLLO_KEY entry (one Secret per Supergraph resource). It deletes the key automatically when the Supergraph resource is deleted.

note
Do not create or delete Supergraph API keys manually. The operator manages their full lifecycle.

Use dedicated API keys and rotate them regularly

Operator API keys don't expire by default—they remain valid until explicitly revoked. You can optionally enable an expiration date using the GraphOS Platform API setKeyExpiration mutation, but the operator doesn't monitor key expiration autonomously. If you set an expiration date, rotate the key before that date.

To check whether an expiration date has been set on a key and retrieve a key's ID, run:

Bash
rover api-key list <ORGANIZATION_ID>

Monitor usage for API keys

Leverage audit logs to monitor API key usage patterns.

Namespace scoping

Configure the operator to only access specific namespaces to reduce the attack surface:

YAML
1config:
2  controllers:
3    subgraph:
4      namespaces:
5        - products-subgraph
6        - orders-subgraphs
7    supergraph:
8      namespaces:
9        - apollo
10    supergraphSchema:
11      namespaces:
12        - apollo

Security checklist

Before deploying to production, verify:

  • API key stored in Kubernetes Secret

  • Using dedicated API key

  • Namespace-scoped RBAC and configuration

  • Service account with minimal required permissions