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.

Required artifacts¶

Please prepare and submit the following:

Item	Where to submit
Authorization Boundary Diagram	Authorization Boundary Diagram section of the BoE
Product networking requirements	Authorization Boundary Diagram section of the BoE
Third-party software and services	Authorization Boundary Diagram section of the BoE
Application database requirements	Authorization Boundary Diagram section of the BoE
List of running containers	Images section of the BoE
Environment variable keys and secrets overview	Submit to your Mission Success Manager via a secure link (e.g., a password-protected share)
Helm charts	Push to Harbor Registry or upload to Game Warden app
Infrastructure as Code (IaC) configurations	Upload to Game Warden app or submit to your Mission Success Manager via a secure link (e.g., a password-protected share)

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
Instance type or minimum vCPU, memory, and storage requirements

Example

App X uses a containerized MySQL database that stores user profiles. Data is encrypted at rest and compatible with any SQL backend. Minimum requirements: 2 vCPU, 4 GB memory, 50 GB storage.

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. 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.

7. Helm charts¶

Game Warden requires Helm charts and uses an internal tool (Helminator) to generate required deployment artifacts.

What to include:

Complete Helm chart
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.

8. Infrastructure as Code (IaC) configurations¶

Provide the Infrastructure as Code used to provision and configure your application's environment(s). This gives the 2F team a 1:1 parity reference when deploying your application into Game Warden, reducing configuration drift and rework.

Terraform is the preferred format. If your team uses a different IaC tool (e.g., CloudFormation, Pulumi, Ansible), submit what you have and note the tooling used.

What to include:

Complete IaC configuration files (for example .tf files and modules for Terraform)
Provider and version requirements
Variable definitions and expected values (excluding secrets)
Any environment-specific configuration (dev, staging, prod) relevant to deployment

Important

Do not include actual secrets, credentials, or sensitive values in submitted IaC files. Use variable references or placeholders instead.

Your IaC should align with the components and flows shown in your Authorization Boundary Diagram.