System Architecture

System Data Nature

This system is intended to store data pertaining to the operations of GSA Fleet operations. The data encompasses vehicles, insurance agencies, vehicle users and system operators. This will amount to complying with FISMA moderate data classification.

Data is encrypted at rest using a KMS key with RSA 2048 encryption (using RSAES_OAEP_SHA_256 encryption algorithms) that meets GSA security standards. Data at transit is encrypted using TLSv2 channel. The system does not hold any PII/PCI data.

All encryption keys are managed using AWS KMS CMK (customer managed keys) for AWS services including S3, RDS, and EBS. All access to keys are available only to privileged users. Access to KMS is via the AWS console, or through the CI/CD pipeline. Any encryption keys external to AWS KMS are stored using AWS Secrets. Again, access to AWS Secrets is available only to privileged users either via console or via the CI/CD pipeline.

CI/CD Pipeline

CI/CD Pipeline: This diagram shows continuous integration and continuous deployment used to build and release application artifacts.

GSAFleet.gov utilizes trunk based branching strategy where the `main` branch is protected and can only be updated via Pull Requests (PR) from a feature branch. GitHub is integrated with GSAFleet.gov Jenkins. GSAFleet.gov Jenkins is configured with a multi-branch declarative pipeline for each application repository. The `main` branch is protected and can only be updated via PR. Each Pull Request goes through gated security checks - SonarQube, Stackrox, unit testing - before that branch is available for code review. In addition, we use Github.com CODEOWNERs (About Code Owners) feature which automatically assigns code reviewers. Upon successful merge to the ‘main’ branch, docker image is built and is deployed to the development environment.

Application Flow:

GSAfleet.gov with this release will support the following features for all the Agency Owned vehicles.

• Recalls
• Mileage History
• Expenses
• Manage repairs
• FAST Reports
• Vehicle data updates
• Registration of vehicles

Recalls: GSAFleet.gov interfaces with CARFAX to get the recalls weekly. The customer has the ability to view the recall and add the remediation details and close it.

Mileage History: For the agencies which are under the GORP (Govt. Odometer Reading at Pump) program the expenses transaction from WEX are used to capture the mileage. This is used to calculate the mileage history for the vehicle. In addition to GORP captures system allows the customers to enter the mileage using file upload and screen updates.

Expenses: GORP agencies capture expenses along with the mileage. Other agencies also get to capture the expenses via uploads and screen updates.

Manage Repairs: The FedFMS agencies can enter the repairs and manage them. GSAfleet.gov provides a basic repair inventory system.

FAST Reports: GSAfleet.gov uses the expenses, mileage history and customer driven data provided by the agencies to generate the FAST report.

Vehicle updates: GSAfleet.gov provides the ability for agencies to update the Vehicle data including the Customer Driven Data (CDD) to maintain the proper vehicle information.

Registration of Vehicles: GSAFleet.gov provides the ability for agencies to register their vehicles. Users can verify the tags they received from UNICOR

GSAFleet.gov is a VPCaaS tenant within FAS Cloud Services (FCS). FCS has GSA issued Authorization to Operate (ATO) and resides on top of Amazon Web Services (AWS) Infrastructure that has an agency FedRAMP authorization. The overall boundary for GSAFleet.gov encompasses GSAFleet.gov Management and GSAFleet.gov Production VPC. The VPC and underlying control domains provide a layer of protection to enhance each boundary, both external and internal. This is achieved utilizing AWS services including route tables, NACLs, and security groups.

GSAFleet.gov architecture uses separate AWS accounts/VPCs (production, test, dev) to segregate production and non-production traffic. The Management VPC is a shared environment that is used to manage different environments using DevSecOps tools (Jenkins, SonarQube, Stackrox) and CI/CD pipeline.

All GSAFleet.gov software and network components are approved by the GSA Enterprise Architecture Review Committee. Furthermore, all baseline operating systems are hardened based upon GSA Security Engineering published hardening guidelines where available or CIS level 1 hardening requirements if otherwise.

Code Scanning

As part of the developer’s Integrated development environment, Sonarlint plugin is available to perform static code analysis before it is checked into GitHub. GSAFleet.gov pipeline uses SonarQube for static code analysis. SonarQube is configured with default quality profiles which are used for static code analysis. GSAFleet.gov pipeline also uses SecOps Stackrox to scan docker images for security vulnerabilities. Stackrox also scans for dependency analysis.

Manual code reviews which are part of Pull Request checks for secrets.

Dependency Scanning

We use Stackrox along with the artifactory. Stackrox scans all the artifacts and dependencies, creating a component graph. This provides complete visibility, enabling Stackrox to determine the impact of any vulnerability or issues discovered in the software.

We have also enabled GitHub’s dependency insights that provides an overview of the opens source dependencies.

GSAFleet.gov CI pipeline is initiated when Pull Request is initiated to merge a feature branch to ‘main’ branch. One of the stages in the pipeline is to scan for security vulnerabilities using Stackrox. If Stackrox identifies security vulnerabilities or license violation, the PR is blocked/rejected preventing vulnerable code from advancing.

We follow SecOps policies to address the vulnerabilities. User stories are created to address each vulnerability in Jira and tracked to closure.

Image Management

GSAFleet.gov infrastructure consists of Linux/Windows components and container images within its boundaries. GSAFleet.gov uses GSA SecEng provided base AMIs and base images. When a new base AMI or base image is released by SecEng, GSAFleet.gov platform team uses AWS EKS services feature to replace existing Linux hosts with new patched Linux AMIs. A similar process is employed for base images. Application container images are rebuilt using new patched base images and rolled out to all the environments.

Secret and Key Management

KMS are used to encrypt AWS resources including EBS, and RDS. AWS CloudTrail is configured to monitor and generate alerts for improper uses of these keys. AWS secrets manager is used for storing secrets needed by applications including database passwords. AWS IAM role service is used to pass these secrets to the application transparently.

GSAFleet.gov uses DevSecOps tools including GitHub, Jenkins, SonarQube, and Stackrox to implement an automated continuous integration and continuous deployment pipeline.

All GSAFleet.gov source code is stored in Github.com (GSA organization). Application development follows trunk based development where the ‘main’ branch is protected and can only be updated via Pull Request (PR) and any environment can only be updated by docker image built from this ‘main’ branch.

GSAFleet.gov Jenkins is configured with a multi-branch declarative pipeline for each application code repository. When a developer submits a PR, Jenkins job is kicked off automatically using GitHub to Jenkins webhook. These Jenkins jobs go through gated security checks - SonarQube, and Stackrox - before that branch is available for code review. Upon successful merge to the ‘main’ branch, docker image is built and tagged with ‘dev’ tag.

GSAFleet.gov product owners will review the release features ready for production implementation in JIra and approve them. When this container image is ready for a higher environment, a higher environment tag is attached which pushes this image to the corresponding environment.

Container images in GSAFleet.gov are continuously scanned for vulnerabilities by the Stackrox agent installed in Kubernetes clusters.

GSAFleet.gov source code is maintained in GitHub.com under GSA organization. The source code is organized into several repositories to match microservices. GSAFleet.gov utilizes trunk based branching strategy where the ‘main’ branch is protected and can only be updated via Pull Requests (PR) from a feature branch. GitHub is integrated with GSAFleet.gov Jenkins.

Unit tests are developed as part of feature development, these tests are run in the CI pipeline and code coverage reports for the same are recorded in SonarQube. End to end tests are developed separately where business flows are tested, these tests are periodically run in the development environment by means of a separate Jenkins pipeline. Any failures in this pipeline will result in a defect created for the application team.

GSAFleet.gov uses a combination of terraform scripts and helm charts to maintain infrastructure in AWS. Terraform is primarily used to launch/deploy AWS services while helm charts are used to launch/deploy pipeline tools. These scripts and configuration as maintained in GitHub repo - GSAFleet.gov-platform. Any updates to infrastructure are first applied and verified in the Dev environment. Upon successful testing and verification, they are pushed to the Production environment.

GSAFleet.gov follows GSA/FCS practice of separate VPCs for development, test, and production environments which are all managed via a management VPC. GSAFleet.gov pipeline tools including Jenkins are deployed in management VPC. GSAFleet.gov Jenkins is configured with a multi-branch declarative pipeline for each application repository. The ‘main’ branch is protected and can only be updated via PR. Each Pull Request goes through gated security checks - SonarQube, Stackrox, unit testing - before that branch is available for code review. In addition, we use Github.com CODEOWNERs (About Code Owners) feature which automatically assigns code reviewers.

Upon successful merge to the ‘main’ branch, docker image is built and is deployed to the development environment. Production will be a manual deployment upon successful testing and approval.

FCS provides MFA authentication and authorization for AWS management console. AWS management console access follows the MFA process - first factor is username and password, and second factor is an OTP code which is emailed to the user's GSA email account. FCS also manages mapping of each user to appropriate IAM roles (e.g. FullAdmin, SysAdmin etc.).

GSAFleet.gov Platform team manages API level access to AWS accounts. An IAM user is created with AWS access key and secret access key. These IAM users utilize the same IAM policies (SysAdmin, FullAdmin etc) providing the same level of access as via management console. The AWS access key and secret access key are not used by application at run-time, and only used for automated provisioning of infrastructure.

GSAFleet.gov Platform team also manages the IAM role attached to AWS resources. These IAM roles provide appropriate access from an AWS resource (e.g. EKS cluster) to another AWS resource (e.g. S3 bucket).

GSAFleet.gov consists of 4 separate AWS accounts - Management, Dev, Test, and Production. The Management account is connected to the other three AWS accounts using AWS VPC peering. There is no network connectivity between the dev, test, and production VPCs/Accounts.

GSAFleet.gov CI/CD pipelines running in the Management VPC are responsible for building, deploying and promoting new application features from lower environments to production.

GSAFleet.gov is architected using GSA and AWS best practices for high availability of applications in the GSAFleet.gov production environment. GSAFleet.gov network design incorporates AWS best practices including multiple AZ deployments, use of AWS CloudFront, WAF and Advanced Shield services for secure public websites, ensuring traffic flows over GSA network or AWS private networks.