Skip to content

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 help the Second Front (2F) team understand how your system functions and how it should be deployed securely.

Note

  • Submit diagrams and visuals in .jpeg, .png, or .pdf formats.
  • Submit Dockerfiles in .txt format.

Required artifacts

Please prepare and submit the following:

  1. Authorization boundary diagram  
  2. Product networking requirements  
  3. Third-party software and services  
  4. Application database requirements  
  5. List of running containers  
  6. Dockerfiles (.txt format)  
  7. Environment variable keys / secrets overview  
  8. Helm charts or Docker Compose files (Helm preferred)

Info

Learn more about Supported Design Patterns and Architectures.

1. Authorization boundary diagram

Provide a visual diagram of your product’s architecture, clearly 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 multiple apps)

Example

Inbound                                Outbound                                
8.8.8.8:443 – datasource for XYZ     103.92.44.2:3306 – MySQL DB for XYZ    

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—especially those not embedded directly in your codebase.

Example

  • Application X consumes RabbitMQ traffic from a DISA IL4 environment  
  • Application X connects to GCCS-J at Scott AFB  
  • Application Y processes S3 uploads via Lambda trigger

These external services must be shown in your Authorization Boundary Diagram to accurately depict the system boundary.

4. Application database requirements

Describe your database usage and deployment needs:

  • Type of database (e.g., MySQL, PostgreSQL, SQL-compatible)
  • Where it’s hosted (internal container, managed cloud service, etc.)
  • Data encryption, retention, or replication concerns

Example

App X uses a containerized MySQL database that stores user profiles. Data is encrypted at rest and compatible with any SQL backend.

Your database must also be represented in your Authorization Boundary Diagram.

5. Running containers

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

What to include:

  • Each container name and associated image
  • Deployment method (e.g., Kubernetes or Docker Swarm)
  • Exposed ports

Example

Name              Mode        Replicas Image                         Ports           
my_app          Replicated 1/1       my_app:latest               *:443 → 443     
my_app_postgres Replicated 1/1       my_app_postgres:latest      *:8100 → 8100   
rabbitmq        Replicated 1/1       docker.io/rabbitmq:latest   *:5671 → 5671   

These containers should also be reflected in your Authorization Boundary Diagram to ensure a complete view of deployed components.

6. Dockerfiles

Submit all Dockerfiles in .txt format. These help our team proactively review application dependencies, identify embedded software, and ensure adherence to best practices.

7. Environment variable keys and secrets

List all environment variable keys used by your application, along with their purpose or function. Do not include actual secrets or passwords.

What to include:

  • Variable name (the “key”)
  • Description of what it’s used for

Example

mysql_db_password: Authenticates DB access from the application

Important

Submit only keys and descriptions. Do not submit the actual values. Game Warden is not requesting secrets, only the structure of what your application expects.

8. Helm charts or Docker Compose files

Game Warden prefers Helm charts and uses an internal tool (Helminator) to generate required deployment artifacts. While Docker Compose files are accepted initially, customers are expected to 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.

Note

If you’re not already using Helm, familiarize yourself with Kubernetes-based deployments prior to onboarding.