mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-15 01:12:56 +03:00
docs: incorporate fixes and reorder cloud-dbs
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6673 GitOrigin-RevId: 0eebba2a04f9109734c28c9b5da6d16e00e60ee1
This commit is contained in:
Rob Dominguez
hasura-bot
parent
342391f39d
commit
1e1592c254
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- aws rds aurora
|
||||
sidebar_label: AWS RDS Aurora Postgres
|
||||
sidebar_position: 3
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- aws rds postgres
|
||||
sidebar_label: AWS RDS Postgres
|
||||
sidebar_position: 4
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -9,7 +9,7 @@ keywords:
|
||||
- azure
|
||||
- cosmos
|
||||
sidebar_label: Azure Cosmos DB
|
||||
sidebar_position: 4
|
||||
sidebar_position: 6
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- azure
|
||||
sidebar_label: Azure Postgres
|
||||
sidebar_position: 5
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- crunchy
|
||||
sidebar_label: Crunchy Postgres
|
||||
sidebar_position: 6
|
||||
sidebar_position: 9
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- digital ocean
|
||||
sidebar_label: Digital Ocean Postgres
|
||||
sidebar_position: 7
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -9,7 +9,7 @@ keywords:
|
||||
- elephant
|
||||
- elephantsql
|
||||
sidebar_label: ElephantSQL Postgres
|
||||
sidebar_position: 8
|
||||
sidebar_position: 11
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -9,7 +9,7 @@ keywords:
|
||||
- enterprisedb
|
||||
- EnterpriseDB
|
||||
sidebar_label: EnterpriseDB (BigAnimal) Postgres
|
||||
sidebar_position: 9
|
||||
sidebar_position: 12
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- existing database
|
||||
- guide
|
||||
- gcp
|
||||
sidebar_position: 10
|
||||
sidebar_position: 13
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- heroku
|
||||
sidebar_label: Heroku Postgres
|
||||
sidebar_position: 11
|
||||
sidebar_position: 14
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -82,6 +82,14 @@ specific cloud vendors.
|
||||
<h5>Azure Cosmos</h5>
|
||||
</div>
|
||||
</VersionedLink>
|
||||
<VersionedLink to='/databases/connect-db/cloud-databases/mssql'>
|
||||
<div className='card-wrapper'>
|
||||
<div className='card'>
|
||||
<img src={MSSQL} title='MS SQL on Azure' alt='Connect MS SQL on Azure to Hasura' />
|
||||
</div>
|
||||
<h5>Azure MS SQL</h5>
|
||||
</div>
|
||||
</VersionedLink>
|
||||
<VersionedLink to='/databases/connect-db/cloud-databases/azure'>
|
||||
<div className='card-wrapper'>
|
||||
<div className='card'>
|
||||
@ -134,14 +142,6 @@ specific cloud vendors.
|
||||
<h5>GCP Postgres</h5>
|
||||
</div>
|
||||
</VersionedLink>
|
||||
<VersionedLink to='/databases/connect-db/cloud-databases/mssql'>
|
||||
<div className='card-wrapper'>
|
||||
<div className='card'>
|
||||
<img src={MSSQL} title='MS SQL on Azure' alt='Connect MS SQL on Azure to Hasura' />
|
||||
</div>
|
||||
<h5>Azure MS SQL</h5>
|
||||
</div>
|
||||
</VersionedLink>
|
||||
<VersionedLink to='/databases/connect-db/cloud-databases/neon'>
|
||||
<div className='card-wrapper'>
|
||||
<div className='card'>
|
||||
|
||||
@ -10,8 +10,8 @@ keywords:
|
||||
- mssql
|
||||
- azure
|
||||
- azure sql
|
||||
sidebar_label: MS SQL on Azure
|
||||
sidebar_position: 11
|
||||
sidebar_label: Azure MS SQL
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -10,7 +10,7 @@ keywords:
|
||||
- integration
|
||||
- serverless
|
||||
sidebar_label: Neon Postgres
|
||||
sidebar_position: 12
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- railway
|
||||
sidebar_label: Railway Postgres
|
||||
sidebar_position: 13
|
||||
sidebar_position: 16
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- render
|
||||
sidebar_label: Render Postgres
|
||||
sidebar_position: 14
|
||||
sidebar_position: 17
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- guide
|
||||
- supabase
|
||||
sidebar_label: Supabase Postgres
|
||||
sidebar_position: 15
|
||||
sidebar_position: 18
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- existing database
|
||||
- guide
|
||||
- timescale
|
||||
sidebar_position: 16
|
||||
sidebar_position: 19
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -8,7 +8,7 @@ keywords:
|
||||
- existing database
|
||||
- guide
|
||||
- yugabyte
|
||||
sidebar_position: 17
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
@ -14,9 +14,10 @@ sidebar_position: 105
|
||||
|
||||
# Best Practices
|
||||
|
||||
Best practices are the goal of all organizations with many different facets benefiting from those practices. This is
|
||||
particularly true with enterprise software and Hasura is no different. The guides below are broken down by category.
|
||||
Best practices are the goal of all organizations with many different facets benefiting from those practices. This is
|
||||
particularly true with enterprise software and Hasura is no different. The guides below are broken down by category.
|
||||
|
||||
- [Metadata](/metadata.mdx)
|
||||
- [Observability](/observability.mdx)
|
||||
- [Security](/security.mdx)
|
||||
- [Database Observability](/deployment/best-practices-for-production/db-observability.mdx)
|
||||
- [Metadata](/deployment/best-practices-for-production/metadata.mdx)
|
||||
- [Observability](/deployment/best-practices-for-production/observability.mdx)
|
||||
- [Security](/deployment/best-practices-for-production/security.mdx)
|
||||
|
||||
@ -28,6 +28,6 @@ access to your GraphQL endpoint and the Hasura console:
|
||||
If you're looking at adding access control rules for your data to your GraphQL API then head to
|
||||
[Authentication / access control](/auth/index.mdx). You can also find more information about
|
||||
[Hasura security in general here](/security/index.mdx) and best practices
|
||||
[here](/guides/best-practices-for-production/security.mdx).
|
||||
[here](/deployment/best-practices-for-production/security.mdx).
|
||||
|
||||
:::
|
||||
|
||||
@ -1,22 +0,0 @@
|
||||
---
|
||||
title: 'Best Practices'
|
||||
description: Best practices for running Hasura in production environments
|
||||
keywords:
|
||||
- hasura
|
||||
- docs
|
||||
- guide
|
||||
- best practices
|
||||
- production
|
||||
slug: index
|
||||
sidebar_label: Best Practices for Production Environments
|
||||
---
|
||||
|
||||
# Best Practices
|
||||
|
||||
Best practices are the goal of all organizations with many different facets benefiting from those practices. This is
|
||||
particularly true with enterprise software and Hasura is no different. The guides below are broken down by category.
|
||||
|
||||
- [Database Observability](/guides/best-practices-for-production/db-observability.mdx)
|
||||
- [Metadata](/guides/best-practices-for-production/metadata.mdx)
|
||||
- [Observability](/guides/best-practices-for-production/observability.mdx)
|
||||
- [Security](/guides/best-practices-for-production/security.mdx)
|
||||
@ -1,81 +0,0 @@
|
||||
---
|
||||
description: Metadata best practices
|
||||
keywords:
|
||||
- hasura
|
||||
- docs
|
||||
- best practices
|
||||
sidebar_label: Metadata
|
||||
---
|
||||
|
||||
# Metadata Best Practices
|
||||
|
||||
Proper Metadata management ensures the Hasura GraphQL Engine operates appropriately and as expected. You can use several
|
||||
different patterns to manage Metadata successfully. However, the below do's, and don'ts have been gathered through
|
||||
real-world practices, user experiences, and challenges when managing enterprise-scale Hasura ecosystems.
|
||||
|
||||
### Recommended patterns
|
||||
|
||||
- Use the [Hasura CLI](/hasura-cli/index.mdx) to manage and export Metadata.
|
||||
|
||||
- The CLI exports [YAML files](/migrations-metadata-seeds/manage-metadata.mdx) which is much more source-control
|
||||
friendly than JSON (exported by the Console and API).
|
||||
- Using the [Hasura CLI Console](/hasura-cli/commands/hasura_console.mdx) will capture all Metadata changes in the
|
||||
local file system as the changes are made.
|
||||
|
||||
- Use the [Hasura CLI Console](/hasura-cli/commands/hasura_console.mdx) as your development Console.
|
||||
|
||||
- [Disable the Hasura GraphQL default Console](/deployment/production-checklist.mdx#disable-console).
|
||||
- Changes via the CLI Console will be detected and will update the local file system.
|
||||
|
||||
- Leverage a version control solution such as GitHub or GitLab as the source of truth for the Metadata configuration.
|
||||
- Local files updated by the CLI Console are then committed to the source control solution.
|
||||
- We recommend retaining the CLI-exported file structure for ease of use.
|
||||
|
||||
- Automate deployments using tools such as GitHub Actions, Jenkins, or the
|
||||
[CLI-migrations image](/migrations-metadata-seeds/auto-apply-migrations.mdx).
|
||||
|
||||
:::info Note
|
||||
|
||||
Hasura Cloud users can leverage the [GitHub integration](/deployment/hasura-cloud/ci-cd/github-integration.mdx) to
|
||||
automate deployments.
|
||||
|
||||
:::
|
||||
|
||||
- Ensure good regression testing is implemented as part of the deployment workflow.
|
||||
- [graphqurl](https://github.com/hasura/graphqurl) is a simple tool that can be used to execute GraphQL queries and
|
||||
compare the results to known values.
|
||||
|
||||
Use the Enterprise Edition for local development if the other Hasura tiers are Enterprise Edition. Using this image is
|
||||
required to allow for the configuration of Hasura Enterprise features (i.e., read-replicas), so the Hasura CLI will
|
||||
include the configurations in the exported Metadata.
|
||||
|
||||
### Patterns to avoid
|
||||
|
||||
- Don't use the Console or API to export Metadata.
|
||||
|
||||
- The Console and API export JSON files that are not as source-control friendly as YAML (exported by the CLI).
|
||||
|
||||
- Don't use the Hasura GraphQL default Console as your development Console.
|
||||
|
||||
- Changes made via the Hasura GraphQL default Console will not capture Metadata changes and can easily cause systems
|
||||
to be out of sync.
|
||||
|
||||
- Don't rely on the local file system or the Hasura Metadata database as the source of truth for the Metadata
|
||||
configuration.
|
||||
|
||||
- Local files can easily be unintentionally modified, corrupted, or lost.
|
||||
- You can unintentionally modify the Hasura Metadata database through misapplication of Metadata changes.
|
||||
- The Hasura Metadata database could be unintentionally lost if you accidentally delete the supporting database or
|
||||
persistent volume.
|
||||
|
||||
- Don't manually deploy. While this will work in practice, it will quickly grow beyond a reasonable level of effort as
|
||||
the system's complexity and frequency of deployments increase.
|
||||
|
||||
- Don't skip good regression testing as Metadata changes can easily change the fundamental way the Hasura GraphQL Engine
|
||||
operates. Queries you structure differently may return unexpected results. You could modify security policies such as
|
||||
RBAC permissions or allowed queries via Metadata changes that cause unexpected behavior.
|
||||
|
||||
- Don't apply Metadata generated from the Community Edition to an Enterprise Edition system that has EE features
|
||||
configured (e.g., read-replicas). Hasura stores these configurations in the Metadata, and the Community Edition cannot
|
||||
configure these features. The resulting exported Metadata will not contain these values, and this Metadata would
|
||||
overwrite the Enterprise Edition configurations if you applied it.
|
||||
@ -1,130 +0,0 @@
|
||||
---
|
||||
title: 'Best Practices: Observability'
|
||||
description: Observability best practices
|
||||
keywords:
|
||||
- hasura
|
||||
- docs
|
||||
- best practices
|
||||
sidebar_label: Observability
|
||||
---
|
||||
|
||||
# Observability Best Practices
|
||||
|
||||
The purpose of this document is to provide an overview of some of the best practices to follow when you configure
|
||||
observability for your Hasura-driven product. We will cover the fundamentals of observability and provides general
|
||||
recommendations on what Hasura considers as observability best practices.
|
||||
|
||||
While specifics of your product or system will define your configurations, we have used Hasura Cloud, Postgres, and
|
||||
Datadog to build this guide. Wherever applicable, links are provided to the mentioned product’s documentation.
|
||||
|
||||
A sample dashboard based on Datadog is provided for you to replicate.
|
||||
|
||||
## The basics
|
||||
|
||||
### What is observability?
|
||||
|
||||
The ability to gauge a system's internal conditions by looking at its outputs is known as observability. If the current
|
||||
state of a system can be determined solely from information from outputs, such as sensor data, then the system is said
|
||||
to be "observable.”
|
||||
|
||||
Without observability, it would be challenging to figure out what is wrong with the system unless you were actively
|
||||
monitoring the system for issues. Observability means you can:
|
||||
|
||||
- Gain insights into the functionality and health of your systems, collect data, visualize them, and set up alerts for
|
||||
potential problems.
|
||||
- Have distributed tracing provide end-to-end visibility into actual requests and code, helping you to improve the
|
||||
performance of your application.
|
||||
- Audit, debug, and analyze logs from all your services, apps, and platforms at scale.
|
||||
|
||||
### Three pillars of observability
|
||||
|
||||
The three pillars of observability are logs, metrics, and traces. Access to logs, metrics, and traces does not
|
||||
automatically make systems more visible. But in combination, they are potent tools that, when properly understood, allow
|
||||
the creation of observable systems.
|
||||
|
||||
## Observability in Hasura
|
||||
|
||||
### Hasura Cloud
|
||||
|
||||
Hasura Cloud projects include dashboards for observability. You will find your monitoring dashboard under the
|
||||
`Monitoring` tab of your Hasura cloud project.
|
||||
|
||||
The following default observability options are enabled on your Hasura Cloud project:
|
||||
|
||||
- [Stats Overview](/observability/overview.mdx)
|
||||
- [Errors](/observability/errors.mdx)
|
||||
- [Usage Summaries](/observability/usage.mdx)
|
||||
- [Operations](/observability/operations.mdx)
|
||||
- [Websockets](/observability/websockets.mdx)
|
||||
- [Subscription Workers](/observability/subscription-workers.mdx)
|
||||
- [Distributed Tracing](/observability/tracing.mdx)
|
||||
- [Query Tags](/observability/query-tags.mdx)
|
||||
|
||||
#### Third-party observability platforms
|
||||
|
||||
If your organization has multiple applications and systems that need to be monitored, the most efficient way to do so is
|
||||
via an observability platform. Hasura provides first-party integrations with multiple observability platforms and is
|
||||
fully open-telemetry compliant. You can find a list of third-party observability platforms supported by Hasura
|
||||
[here](/observability/integrations/index.mdx).
|
||||
|
||||
### Hasura Enterprise (self-hosted)
|
||||
|
||||
Since your Hasura Enterprise is self-hosted (on-premises or on a third-party cloud), we recommend that you enable
|
||||
monitoring for your containers and pods. Your organization can make better decisions by knowing what is happening at the
|
||||
cluster or host level and within the container runtime and application. This level of information allows you to make
|
||||
decisions like when to scale instances, tasks and pods in or out, as well as which instance types to use.
|
||||
|
||||
#### Logs
|
||||
|
||||
Depending on your Hasura Enterprise Edition deployment mode, you may access, export, and process logs from your
|
||||
deployment using [this](/deployment/logging.mdx#log-types) document. Generally, you should configure your container logs
|
||||
to be exported to your observability platform using the appropriate log drivers.
|
||||
|
||||
#### Metrics via Prometheus integration
|
||||
|
||||
You can export metrics of your Hasura Cloud project to Prometheus. You can configure this on the `Integrations` tab on
|
||||
the project's settings page. You can find more information on this [here](/enterprise/metrics.mdx). This page also
|
||||
provides information about different metrics exported from Hasura to Prometheus.
|
||||
|
||||
## Database observability
|
||||
|
||||
Deeper insight into databases across all of your servers is provided via database monitoring. To understand the
|
||||
performance and health of your databases and address problems as they develop, we have to dig deeper into:
|
||||
|
||||
- Historical query performance
|
||||
- Host-level metrics
|
||||
|
||||
### Enabling observability agents in your database
|
||||
|
||||
You can enable observability for your databases by installing an agent for your observability platform on your database
|
||||
servers (typically from the observability tool’s marketplace). Hasura recommends the following instrumentations should
|
||||
be implemented:
|
||||
|
||||
- System information
|
||||
- CPU Usage
|
||||
- Memory
|
||||
- Query Tags
|
||||
|
||||
[Query Tags](/observability/query-tags.mdx) are SQL comments that consist of `key=value` pairs that are appended to
|
||||
generated SQL statements. When you issue a query or mutation with query tags, the generated SQL has some extra
|
||||
information. Database analytics tools can use that information (metadata) in these comments to analyze DB load and track
|
||||
or monitor performance.
|
||||
|
||||
### Using Query Tags and pganalyze
|
||||
|
||||
- Refer to documentation from [pganalyze](https://pganalyze.com/docs) for information on how to connect your database to
|
||||
the analyzer.
|
||||
- Once connected to your database, test the functionality by:
|
||||
- Executing the `run console` option in pganalyze.
|
||||
- Executing the `collector --test` command in the console.
|
||||
- At this point, all queries run from the GraphiQL editor or your Cloud project's console will appear in the pganalyze
|
||||
console.
|
||||
- Selecting any query from the dashboard will expand to give additional information about the execution.
|
||||
- To quickly locate operations, you can use the `Request ID` that can be found from the `Metrics` dashboard on Cloud.
|
||||
|
||||
## Alerting and alert propagation
|
||||
|
||||
Integrating your observability tools with an incident response platform (IRP) is the recommended method for alert
|
||||
propagation. Integrating with an IRP allows high visibility and actionable intelligence across the entire incident
|
||||
lifecycle. Most IRPs enable your organization to respond quickly to incidents, automate responses, and will allow you to
|
||||
build more reliable services and platforms.
|
||||
@ -1,178 +0,0 @@
|
||||
---
|
||||
description: Security best practices for a production environment
|
||||
keywords:
|
||||
- hasura
|
||||
- docs
|
||||
- best practices
|
||||
- production
|
||||
sidebar_label: Security
|
||||
---
|
||||
|
||||
import Thumbnail from '@site/src/components/Thumbnail';
|
||||
|
||||
# Security Best Practices
|
||||
|
||||
## Introduction
|
||||
|
||||
This guide reviews security best practices that should be implemented for a production environment. Applying API
|
||||
security beyond RBAC (role-based access control) permissions is mandatory for any API moving towards a production
|
||||
deployment. We recommend that all HTTP layer security work be done at the API gateway level and GraphQL-specific
|
||||
policies be applied at the Hasura level.
|
||||
|
||||
<Thumbnail
|
||||
src='/img/guides/best-practices-security-apihasura-diagram.png'
|
||||
alt='Hasura/API security architecture'
|
||||
width='900px'
|
||||
className='no-shadow'
|
||||
/>
|
||||
|
||||
Specifics about each security best practice can be found below.
|
||||
|
||||
## Hasura GraphQL Engine
|
||||
|
||||
#### Restrict Access
|
||||
|
||||
Restrict knowledge of admin secrets to the minimally required team members as an admin secret provides unrestricted
|
||||
access to the Hasura GraphQL Engine. SSO collaboration should be used to grant project access without sharing an admin
|
||||
key. Subsequently, implement a plan to rotate admin secrets to limit the exposure of an admin secret being shared too
|
||||
broadly.
|
||||
|
||||
[Multiple admin secrets](/security/multiple-admin-secrets.mdx) should be used in situations where admin secrets have
|
||||
different rotation timelines or when granting temporary access is needed.
|
||||
|
||||
Leverage [allowed operations lists](https://www.graphql-code-generator.com/plugins/other/hasura-allow-list) whenever
|
||||
possible to restrict unbounded or unexpected operations from being executed against the GraphQL endpoint. Allow lists
|
||||
[must be enabled](/security/allow-list.mdx#enable-allow-list) via environment variable. These lists can be configured
|
||||
globally or at the role level which allows for each role to have a differently defined set of permissible operations.
|
||||
The allow list should include the complete set of expected operations for a given role to restrict the ability for a
|
||||
user to execute non-permissible operations. Consider using the [Hasura Allow List](https://www.graphql-code-generator.com/plugins/other/hasura-allow-list) codegen plugin to
|
||||
automatically generate allow list metadata from your application code.
|
||||
|
||||
:::info Note
|
||||
|
||||
The admin role will bypass the allowed operations list.
|
||||
|
||||
:::
|
||||
|
||||
#### Limit the API
|
||||
|
||||
The allowed operations lists workflow is ideal for private/internal APIs or APIs with well understood and clearly
|
||||
defined operations. Public APIs or APIs with less defined expected operations should additionally configure
|
||||
[depth limits](/security/api-limits.mdx#depth-limits) and [node limits](/security/api-limits.mdx#node-limits).
|
||||
|
||||
- Configure both [rate limits](/security/api-limits.mdx#rate-limits) and
|
||||
[time limits](/security/api-limits.mdx#time-limits) to restrict frequency and duration of operations.
|
||||
|
||||
- [Limit rows](/auth/authorization/permission-rules.mdx#limit-rows-permissions) returned by a select operation.
|
||||
|
||||
#### Permissions
|
||||
|
||||
The row-based access control configuration dictates permissions for the GraphQL API. It is critical that these
|
||||
permissions be configured correctly in order to prevent unauthorized or unintended access to the GraphQL API.
|
||||
|
||||
- Review the [permissions summary](https://hasura.io/docs/latest/deployment/production-checklist/#review-the-summary)
|
||||
for each schema to verify permissions are constructed appropriately for your expected data access.
|
||||
|
||||
- Configure an
|
||||
[anonymous default role](https://hasura.io/docs/latest/auth/authorization/common-roles-auth-examples/#anonymous-users-example)
|
||||
in order to apply global security permissions. This default role should be configured similarly to any other role.
|
||||
This includes [RBAC permissions](https://hasura.io/docs/latest/auth/authorization/basics/),
|
||||
[API limits](https://hasura.io/docs/latest/security/api-limits/),
|
||||
[allowed operations lists](https://www.graphql-code-generator.com/plugins/other/hasura-allow-list) and
|
||||
[disabling schema introspection](https://hasura.io/docs/latest/security/disable-graphql-introspection/).
|
||||
|
||||
#### Restrict request methods to API endpoints {#api-methods}
|
||||
|
||||
Hasura exposes many APIs which might not be relevant for a production instance that is only supposed to serve GraphQL.
|
||||
APIs can be selectively enabled using the corresponding flag or environment variable.
|
||||
|
||||
In most production scenarios, you would only need GraphQL API to be enabled.
|
||||
|
||||
```bash
|
||||
# set this env var to enable only the graphql api
|
||||
HASURA_GRAPHQL_ENABLED_APIS=graphql
|
||||
|
||||
# if you're using flags
|
||||
graphql-engine --database-url=<database-url> serve --enabled-apis=graphql
|
||||
```
|
||||
|
||||
By setting the above flag or env var, we are disabling the `metadata`, `pgdump` and `config` APIs. `health` and
|
||||
`version` APIs are public and cannot be disabled.
|
||||
|
||||
<details>
|
||||
<summary>This table breaks down API endpoints used by Hasura as well
|
||||
as the expected request type(s) for each.</summary>
|
||||
|
||||
| API | Endpoint | Method(s) | Access |
|
||||
| ------------------------------- | -------------------------------------------------------------------------------- | --------------------------- | ---------------- |
|
||||
| GraphQL | [/v1/graphql](/api-reference/graphql-api/index.mdx) | POST | Permission rules |
|
||||
| Relay | [/v1beta1/relay](/api-reference/relay-graphql-api/index.mdx) | POST | Permission rules |
|
||||
| Legacy GraphQL | [/v1alpha1/graphql](/api-reference/graphql-api/index.mdx) | POST | Permission rules |
|
||||
| Schema _(> v2.0)_ | [/v2/query](/api-reference/schema-api/index.mdx) | POST | Admin only |
|
||||
| Metadata _(> v2.0)_ | [/v1/metadata](/api-reference/metadata-api/index.mdx) | POST | Admin only |
|
||||
| Schema/Metadata _(deprecated)_ | [/v1/query](/api-reference/schema-metadata-api/index.mdx) | POST | Admin only |
|
||||
| Restified GQL | [/api/rest](/api-reference/restified.mdx) | GET, POST (query, mutation) | GQL REST Routes |
|
||||
| Version | [/v1/version](/api-reference/version.mdx) | GET | Public |
|
||||
| Health | [/healthz](/api-reference/health.mdx)<br />/hasura/healthz | GET | Public |
|
||||
| PG Dump | [/v1alpha1/pg_dump](/api-reference/pgdump.mdx) | POST | Admin only |
|
||||
| Config | [/v1alpha1/config](/api-reference/config.mdx) | GET | Admin only |
|
||||
| Explain | [/v1/graphql/explain](/api-reference/explain.mdx)<br />/v1alpha1/graphql/explain | POST | Admin only |
|
||||
| RTS stats | /dev/rts_stats | GET | |
|
||||
| ekg | /dev/ekg | GET | Admin only |
|
||||
| Query plan cache _(deprecated)_ | /dev/plan_cache | GET | Admin only |
|
||||
| Subscriptions | /dev/subscriptions<br />/dev/subscriptions/extended | GET | Admin only |
|
||||
| Data Connector | /dev/dataconnector/schema | GET | Admin only |
|
||||
| OpenAPI | /api/swagger/json | GET | Admin only |
|
||||
| Console | /console, /console/assets | GET | |
|
||||
|
||||
</details>
|
||||
|
||||
#### Disable development components
|
||||
|
||||
There are several components of Hasura GraphQL Engine that are crucial for development efforts but should be disabled
|
||||
for a production environment. However, it should be expected that some of these components may need to be temporarily
|
||||
re-enabled if a situation arises where a production environment specific issue requires troubleshooting.
|
||||
|
||||
- [Disable APIs](/deployment/production-checklist.mdx#disable-apis).
|
||||
|
||||
- [Disable the console](/deployment/production-checklist.mdx#disable-console).
|
||||
|
||||
- [Disable dev mode](/deployment/production-checklist.mdx#disable-dev-mode).
|
||||
|
||||
- [Disable schema introspection](/security/disable-graphql-introspection.mdx).
|
||||
|
||||
#### Additional environment variables
|
||||
|
||||
There are specific environment variables that should be configured to ensure appropriate communication to the Hasura
|
||||
GraphQL Engine server.
|
||||
|
||||
- [Allowed CORS requests](/deployment/graphql-engine-flags/config-examples.mdx#configure-cors).
|
||||
|
||||
## Database connections
|
||||
|
||||
Hasura GraphQL Engine communicates with your data sources(s) via ODBC connection strings. This means Hasura has the same
|
||||
permissions as the provided credentials in the connection string.
|
||||
|
||||
- Review the database permissions allocated via the provided credentials to ensure the level of access granted to Hasura
|
||||
is appropriate.
|
||||
|
||||
- Use database connections strings with the least privileges required for API operations.
|
||||
- Configure [read replicas](/databases/connect-db/read-replicas.mdx) to route read-only operations (queries) to one (or
|
||||
many) read replicas.
|
||||
|
||||
## Networking/API gateway
|
||||
|
||||
We recommend the following HTTP layer security policies to be configured at the API gateway:
|
||||
|
||||
- [Configure HTTPS](/deployment/enable-https.mdx) on your reverse proxy to ensure encrypted communication between your client and Hasura.
|
||||
- Implement request and response size restrictions.
|
||||
- Restricted allowed connection time to prevent incidents such as slowloris attacks.
|
||||
- Apply both IP filtering and IP rate limiting.
|
||||
- [Restrict API request methods by endpoint](/deployment/securing-graphql-endpoint.mdx#api-methods) to prevent invalid
|
||||
request methods. This will also allow for custom error messaging at the API gateway when receiving invalid requests.
|
||||
|
||||
Consider using a a
|
||||
[web application firewall](https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/) (WAF) as the
|
||||
first line of defense. A firewall can provide extra protection against common attack types such as cross-site request
|
||||
forgery (CSRF) by filtering and monitoring HTTP traffic between the application and the internet based on a rule set
|
||||
configured by your team. Common WAF solutions include Cloudflare, Akamai and Imperva.
|
||||
Loading…
Reference in New Issue
Block a user