Docs
Launch GraphOS Studio

Securing subgraphs

With GraphOS


To keep your secure, it's important that your individual are

. That's because your expose powerful that the uses to execute across them. External clients should not have access to these fields.

This article describes steps for securing your when using a

.

💡 TIP

As with all changes, we recommend first performing these steps for a non-production of your .

1. Generate a shared secret

To restrict communication to only your , we recommend creating a separate shared secret for each of your subgraphs. Whenever your router queries a subgraph, it includes that subgraph's corresponding secret in an HTTP header.

You can generate a random secret using a variety of tools. For example, most password managers provide this functionality.

Here are some shell commands that generate a suitably random secret if you have the corresponding tool installed:

  • openssl rand -base64 256
  • python -c "import secrets; print(secrets.token_urlsafe(256))"
  • node -e "console.log(require('crypto').randomBytes(256).toString('base64'));"

2. Add the secret to your router config

Your cloud 's needs to know the shared secret so it can include it in all requests to the corresponding . You add the secret in the Cloud Routing section of your 's Settings page.

💡 TIP

For details, see

.

After you define the secret, you can inject its value into your 's configuration as an environment variable, as shown below. We recommend setting the value in a header named Router-Authorization (and again, create a separate secret for each ):

headers:
subgraphs:
products:
request:
- insert:
name: 'Router-Authorization'
value: '${env.PRODUCTS_SUBGRAPH_SECRET}'
users:
request:
- insert:
name: 'Router-Authorization'
value: '${env.USERS_SUBGRAPH_SECRET}'

3. Configure the subgraph to require the secret

The exact steps you take to require the shared secret in your depend on:

  • The language and framework your uses
  • The service you use to host your

Most cloud providers include a mechanism for saving secrets that are then made available to your application as environment variables. Your should read the secret from an environment variable and reject any incoming requests that don't include that secret in the specified header.

ⓘ NOTE

All templates

include this functionality out of the box. To use it, set the value of the ROUTER_SECRET environment variable.

If you have an existing that wasn't created from a template, you can check a similar template's source code for an example.

4. Test the configuration

After adding the shared secret to both your and , do the following to confirm that communication has been secured as intended:

  1. Verify that your can still communicate with the by executing a test against the router from the Explorer.
    • Make sure the includes at least one from the relevant !
  2. Verify that other clients can't communicate with the by executing a test against the subgraph directly.
    • This should fail with an authorization error.
Previous
Graph management
Next
Safelisting with persisted queries
Edit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy

Company