Technical Artifacts are materials you provide to help the Game Warden team better understand your application architecture, design, and operation.
Immediately below are the requested artifacts (with examples that follow):
- Authorization Boundary Diagram
- Product Networking Requirements
- Third-party Software and Services
- Application Database Requirements
- Application’s Running Containers
- Dockerfiles (in a .txt file format)
- Secrets/Environment Variable Keys
- Kubernetes Manifest Files
Authorization Boundary Diagram¶
Provide a visual representation of your product and its associated components. For additional information, read Authorization Boundary Diagram.
Example: IL4/IL5 Boundary Diagram¶
Product Networking Requirements¶
List your product networking requirements. Also, provide a list of applicable egress, ingress, and bidirectional requirements for your product.
It is imperative that you have a complete understanding of your data directional flow:
- Egress – Data leaves or exits the Game Warden boundary.
- Ingress – Data enters the Game Warden boundary.
- Bidirectional – Data leaves and enters the Game Warden boundary.
If there are multiple applications, annotate the rules that apply to each.
|IP: 220.127.116.11 PORT:443 – datasource for xyz||IP: 18.104.22.168 PORT: 3306 – mysql db for xyz|
Third-Party Software and Services¶
List third-party software, external services, and cloud services. Also, list any product services that are not directly embedded.
Application X takes requests from externally-hosted RabbitMQ (22.214.171.124:443) that resides on an IL4 environment operated by the Defense Information Systems Agency (DISA).
Application X integrates directly with a GCCS-J instance at Scott AFB for Order of Battle information.
Application Y relies on data input from end users via S3 buckets. A Lambda function triggers on the upload event and adds the data to the application database.
Application Database Requirements¶
Provide the application database requirements.
App X is currently using a containerized MySQL DB deployed in the host cluster but will work with any SQL-compatible database. The database stores user profile data (name, location, settings) and is encrypted at rest.
Application's Running Containers¶
List your application's running containers. Reference the articles below for instruction and insight:
- For Kubernetes: List of Running Container Images
- For Docker Swarm, run the following command:
docker node ls
|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 -> 56711|
Provide Dockerfiles (in a .txt file format), which help our team proactively identify application dependencies. For additional information, read Best Practices.
Secrets/Environment Variable Keys¶
Environment variables (key-values pairs) can communicate with programs you code/run, controlling program behavior. Each environment variable has a name and a value. On a Windows machine, these variable names are commonly uppercase, and the associated values are commonly strings. On a Linux machine, these variable names are case-sensitive and commonly preceded by a dollar sign ($). PATH is a common environment variable that typically indicates where program executables are located on your machine. Secrets represent anything you want to keep hidden, such as passwords. The safest way to manage secret keys/passwords is by saving them as environment variables.
Provide a Table of Contents (TOC) of environment variables. Also, include the purpose/function of the secrets; however, do not provide the actual secrets. The Game Warden team is not interested in your secrets/passwords, only the keys. For example, the key in the example below is mysql_db_password, and the example passwords are random strings.
mysql_db_password = Key
Random$#Password@@String = Actual Secret
Kubernetes Manifest Files¶
Provide Kubernetes manifest files, if available.