Supported design patterns are specifications the Customer Operations and Sales teams may share with you and prospects such that your applications integrate with the Game Warden platform with relative efficiency and ease.
The Architecture, Security, and General tables below contain application-specific content, designating what the Game Warden team expects you to provide when you send us data and containerized images.
Applications must reside in containers and comply with standards specific to the Open Container Initiative (OCI).
Database seeding services or scripts.
You must have services for seeding databases or provide scripts to the Game Warden team to execute for you. At Impact Level 4 (IL4), you will not have write access to your production database.
Complete applications.
You must ensure applications are complete and functional prior to beginning the Onboarding process.
You should manage your own data and database migrations.
Reliable microservice architecture.
Microservice architecture promotes reliability. For example, adding only one service or application per container provides greater efficiency.
Dummy data for functional testing in the Staging (STG) environment.
Generating dummy data or having an iron clad way to scrub data facilitates the backup and restore processes.
End-to-end automated testing.
You should test your own code.
Structured logs.
Structured logs enable the Game Warden team to more efficiently detect fields and key-value pairs in the log output. If you do not have good log data, it becomes challenging for our team to visualize the state of your applications.
High-level documentation specific to the configuration variables that your microservices use.
Provide API documentation, which is extremely helpful.
Simple Helm charts.
The Game Warden team would like to fold everyone into Helminator. The ideal Helminator import occurs when you have knowledge of your application, how it functions, and what you need. Application simplicity helps. Provide an Authorization Boundary Diagram with details such as ports and protocols.
Write logs to standard output (stdout).
While the Game Warden team’s logs capture standard output (user command results) and standard errors (application errors), log messages commonly are strings that our team must parse and break down into different elements to extract fields. If the data is easy to parse, it helps us visualize the state of your applications. Also, structured logs are easier for Grafana to parse (and Loki to ingest). At minimum, you must document where your logs should reside.
Detailed diagrams.
A highly detailed Authorization Boundary Diagram with all ports and protocols coupled with in-depth application knowledge facilitates Helminator use.
Single points of failure/lack of high availability.
Your applications must function/operate as designed. In this case, the Game Warden team can reduce single points of failure and maintain high availability. This scenario might apply to API services interacting with a database, for example.
Monolithic applications.
This application type increases the workload and overhead for the Operations, Platform, and Web Application teams.
S3 to serve your frontend applications.
The Game Warden team can support use of S3 to serve your frontend applications. For example, we can take your S3 site and convert it into an NGX container and host applications from NGX as opposed to S3.
Your own helm charts.
The Game Warden team prefers to use Helminator. You should know how your application works in a Kubernetes cluster, as the application should run successfully in Kubernetes prior to the Onboarding process. The hope is to move you into Helm despite how you provide your data to us. The ideal input for Helminator is application knowledge and application simplicity, which can be captured in a detailed and thorough Authorization Boundary Diagram that includes ports and protocols.
Helm alternatives (Kustomize/regular manifests).
The Game Warden team can support your helm charts; however, ideally, we prefer to move you to Helminator. There are only two approaches for a Kubernetes manifest: Kustomize or Helm. Either is acceptable. You must have a complete understanding of how your application works in a Kubernetes cluster (for now) until we begin to support other architectures.
Any attempt to move high Impact Level (IL) data to low Impact Levels (ILs).
Moving high IL data to low ILs causes data spillage.
No external data connections outside of Game Warden/Non-classified Internet Protocol Router Network (NIPRNet) boundary.
The Game Warden platform does not support external data connections. This specification is on our Roadmap and will be available in a future release.
No application access outside NIPRNet without Appgate SDP or Air Force Desktop Anywhere.
The Department of Defense (DoD) uses NIPRNet to manage unclassified information. If you use NIPRNet or NIPRNet VPN (such as Air Force Desktop Anywhere), you can access IL4 and IL5 without using Appgate SDP. We require you to use Appgate SDP if you do not use NIPRNet or NIPRNet VPN, as you cannot access IL4 or IL5 without using one of these options.
Permitted data includes Controlled Unclassified Information (CUI), Personally Identifiable Information (PII), IL2, IL4, and IL5 along with data specific to the International Traffic in Arms Regulations (ITAR). You must contact the Game Warden team for data associated with IL6, SPA, or Sensitive Compartmented Information (SCI).
Keycloak Single Sign On (SSO) as the Identity and Access Management (IAM) solution.
Keycloak SSO is the IAM solution that allows you and your users to access the Game Warden Web application, products, and other solutions more securely and using a single set of credentials. Each application in Game Warden must be behind Keycloak SSO.
Meets Authority to Operate (ATO) security.
The Game Warden team continually scans applications for security vulnerabilities, and you must resolve them per the Acceptance Baseline Criteria (ABC). You must regularly update your components to align with ATO security standards, ensuring they remain secure and compliant.
Integrates with DoD-approved authentication services.
The Game Warden team supports two DoD-approved authentication services: Game Warden and Platform One (P1).
Ability to obtain a Common Access Card (CAC), External Certificate Authority (ECA), or Federal Personal Identity Verification (PIV) card.
You and users must have a CAC, ECA, or PIV to access IL4+ applications. You must navigate the DoD/Federal government vetting process to secure a CAC or a PIV (respectively) from a mission sponsor. DoD-approved third parties issue ECAs.
Regular updates.
To ensure applications remain secure and continue to meet the ABC, you must regularly update libraries and components which include vulnerabilities or present a security risk. Depending on the level of assessed risk, more frequent updates will be required.
Architecture Boundary Diagram.
You must submit a detailed Authorization Boundary Diagram which clearly shows the components of the application, how the data flows, and any required services or components such as a database or Simple Email Service (SES). The boundary of the Game Warden environment must be captured with any data connections outside of the environment clearly identified (to include sending emails outside of the environment). You should show details such as ports and protocols. More detail is preferred.
Any data transit external to Game Warden requires review on a case-by-case basis, and explicit government approval is required.
Our team will review external transit data, and government approval is required.
Scans of images using an open source version of Anchore.
The Game Warden team scans images using Anchore Enterprise and Prisma Cloud. The free version of Anchore enables you to scan images and mitigate issues before sending us these containerized images. For reference, review: Open Source Security with Syft and Grype
Classification tagging of data.
Tagging data helps us with data identification. For example, tagging data as CUI is useful and helps with data spillage, as we do not want classified data – for example – on a machine or in an environment not permitted to store this type of data.
Base container currently supported by Game Warden.
Game Warden has many containers, such as Universal Base Images (UBIs), that our team sees and uses frequently. This makes us more comfortable, for example, with justifications/remediations. We can navigate these containers more easily because of familiarity, which would not be the case with less familiar or random containers.
Pull data in (request originating within Game Warden boundary).
The Game Warden team can perform a pull request (PR) from the Game Warden environment to retrieve data, preventing entry of data external to NIPRNet.
External connections to system devices in NIPRNet.
If the IP space is listed as NIPRNet, it can be whitelisted. This action makes it easier to approve these external connections.
Iron Bank.
Images which run on unmodified Iron Bank base containers can inherit the justification approvals from Iron Bank if the container continues to meet Iron Bank ABC requirements. If an Iron Bank container no longer meets requirements, the results of the previous assessment can be considered in the Game Warden review process.
Currently, the Game Warden platform cannot support classified data.
Any data movement from a higher IL to a lower IL.
Currently, this action is not supported in Game Warden's design pattern and would result in data spillage.
No use of Game Warden SSO solution for IL4/IL5.
You must use the Game Warden SSO solution for IL4 and IL5.
External connections from IL4/IL5 to a non-accredited system device.
Our team does not support external connections from IL4/IL5 to a non-accredited system device.
Streaming data in (from commercial as a push).
If you want to stream data from commercial sources, you must have a discussion with the Game Warden team to ensure we have a solid understanding of the actual data.
Knowledge/understanding of containerization/microservices/Kubernetes and how applications work in a Kubernetes cluster.
This insight makes it easier for Game Warden team members to speak with you about this topic, as you would understand – for example – how we perform certain actions, why we make certain requests, and why we deploy in a certain manner. In this circumstance, if we ask you to separate applications into microservices, you will understand the request and know how to respond.
Allow Game Warden to host or mirror your code.
This action is on the Roadmap and would make for an ideal customer.
Proactive functional application testing.
You should test your application to ensure the functionality works as designed.
The Game Warden team can provide support if you do not have a DoD contract up to IL2.
Services available in AWS GovCloud East.
The Game Warden team supports customers who use services available in AWS GovCloud East. Currently, there is no presence in AWS GovCloud West; however, there are plans to move in this direction to address potential latency. This action is on the Roadmap.
A list of AWS services, separated by availability in the East and West, that includes the following categories: Have Supported, Can Support, Cannot Support
2.
An approval process for data connections external to Game Warden/NIPRNet.
3.
Development/feature ideas that are in the pipeline, such as streaming and alternate SSO connections.
4.
Plans to allow Game Warden to host or mirror your application code, making for ideal customers.
5.
The Game Warden team supports customers who use services available in AWS GovCloud East. Currently, there is no presence in AWS GovCloud West; however, there may be movement in this direction at some point to address potential latency.