Technical Artifacts

To ensure a smooth onboarding and authorization process, Game Warden requires a set of technical artifacts that describe your application's architecture, configuration, and operational requirements. These materials enable the Second Front team to understand how your system functions and how to deploy it securely.

Required artifacts

Please prepare and submit the following:

1 - Authorization Boundary Diagram

Provide a visual diagram of your product's architecture, outlining all components that fall within and outside the Game Warden boundary. This includes internal services, external integrations, and system dependencies.

Your diagram must represent:

• Networking flows (ingress, egress, bidirectional traffic)
• Third-party software and services
• Databases and storage locations

For more guidance, see Authorization Boundary Diagrams.

2 - Product networking requirements

List all network communication your product requires. Include:

• Ingress, egress, and bidirectional data flows
• IP addresses, ports, and protocols
• Annotations to clarify which flows apply to which services (if you have several apps)

These data flows must also be visually represented in your Authorization Boundary Diagram.

3 - Third-party software and services

List any external tools, APIs, services, or platforms your application integrates with, including those not embedded directly in your codebase.

Include these external services in your Authorization Boundary Diagram to accurately depict the system boundary.

4 - Application database requirements

Describe your database usage and deployment needs:

• Database technology (for example, MySQL, PostgreSQL, SQL-compatible)
• Host location (internal container, managed cloud service, etc.)
• Data encryption, retention, or replication concerns

Include your database in your Authorization Boundary Diagram.

5 - Running containers

List all containers your application uses in production. This allows Game Warden to test your deployment structure and track dependencies during onboarding and scanning.

What to include:

• Each container name and associated image
• Deployment method (for example, Kubernetes or Docker Swarm)
• Exposed ports

Include these containers in your Authorization Boundary Diagram to provide a complete view of deployed components.

6 - Dockerfiles

Submit all Dockerfiles in .txt format. These enable Second Front team to proactively review application dependencies, identify embedded software, and verify adherence to best practices.

7 - Environment variable keys and secrets

Provide a complete list of all environment variables required by your application to run in production, along with a description of what each variable controls.

Submit this document as a .env.example file, a JSON schema, or a Markdown table.

What to include:

• Variable Key: The exact name expected by the application runtime.
• Description: The purpose of the variable (for example, database authentication, feature toggles, external API endpoints).
• Variable Type: Specify whether the item is a standard configuration value or a sensitive secret that requires secure injection at runtime.

8 - Helm charts or Docker Compose files

Game Warden prefers Helm charts and uses an internal tool (Helminator) to generate required deployment artifacts. Game Warden accepts Docker Compose files for initial onboarding, but customers must transition to Helm during onboarding.

What to include:

• Complete Helm chart or Compose file
• Definitions of services, volumes, dependencies, ports, and protocols

Helm inputs should align with the structure and flow shown in your Authorization Boundary Diagram. If you're not already using Helm, familiarize yourself with Kubernetes-based deployments prior to onboarding.