Skip to content

Security

MyGreat separates the control plane from the data plane.

  • The web application stores configuration, schedules work, tracks runs, and presents logs and reports.
  • Runners execute the actual transfer operations against source and target systems.

That split matters for every security claim in the product.

Data path and trust boundary

  • The web application does not proxy file contents through the main web request path.
  • File transfer execution happens inside the runner process that runs the job.
  • A runner therefore needs execution-time access to the credentials, tokens, and provider configuration required for that job.
  • If you deploy external runners in your own environment, you control that execution boundary directly.

This means the strongest accurate statement is:

  • MyGreat keeps the web application out of the direct file-transfer path.
  • The runner environment still has access to the data and credentials needed to perform the transfer.

Token and secret storage

  • Storage Repository Open Authorization (OAuth) token payloads are encrypted at rest in application storage.
  • Application-level encrypted text fields are also encrypted before persistence.
  • The encryption layer uses Fernet-based symmetric encryption.
  • For production deployments, configure dedicated REMOTE_TOKENS_ENCRYPTION_KEYS instead of relying on SECRET_KEY fallback behavior.

Runner authentication

  • Runner registration tokens are stored as salted Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm 256 (SHA-256) hashes.
  • Runner API tokens are also stored as salted HMAC-SHA-256 hashes.
  • The plaintext token value is needed only at issuance time.

Runtime token handling

  • Refresh-token custody now stays with the web application.
  • Runners receive access-token-only runtime payloads where that contract is supported.
  • Runners can request fresh access-token material through a run-scoped refresh endpoint when expiry approaches.

Important boundary:

  • Some Storage Repository types still require runners to receive other secret material needed for execution, such as static credentials, provider client secrets, or service account credentials.
  • Treat runners as trusted execution components and place them in an environment that matches your security requirements.

Identity and access data

  • Email is the canonical user identity key in the application.
  • The application may also store an optional full name from the identity provider.
  • Tenant membership roles control who can administer the tenant and who can only view selected workspaces.

Logs and diagnostics

  • Sensitive values are redacted before run logs are persisted.
  • Read and export paths apply the same redaction again as a fallback for older rows.
  • Redaction is best-effort defense in depth, not a reason to enable verbose authentication dumps in production.

Deployment choices

You can strengthen your security posture by:

  • running external runners in your own infrastructure
  • granting the narrowest Storage Repository permissions that still let the job work
  • configuring dedicated token-encryption keys
  • avoiding verbose provider-level debug modes during normal operation

See also