Merge branch 'development' into 'master'

Development

See merge request !15

.gitlab/CODEOWNERS

-[Pipelines]
-.gitlab-ci.yml @ironbank-notifications/cht
-.gitlab-ci.yaml @ironbank-notifications/cht
-
-[Gitlab Configuration Files]
-.gitlab/* @ironbank-notifications/cht
+[Pipelines]
+.gitlab-ci.yml @ironbank-notifications/cht
+.gitlab-ci.yaml @ironbank-notifications/cht
+
+[Gitlab Configuration Files]
+.gitlab/* @ironbank-notifications/cht

.gitlab/issue_templates/Access Request.md

-## Summary
-
-The following individuals are requesting access to this project (one per line):
-(List or tag all individuals here)
-
-
-The access level should be:
-- [ ] Developer access
-- [ ] Remove access
-
-
-## Definition of Done
-- [ ] All accounts have been provided the necessary accesses
-
-
-
-
-
+## Summary
+
+The following individuals are requesting access to this project (one per line):
+(List or tag all individuals here)
+
+
+The access level should be:
+- [ ] Developer access
+- [ ] Remove access
+
+
+## Definition of Done
+- [ ] All accounts have been provided the necessary accesses
+
+
+
+
+
 /label ~"Access" ~"To Do"
\ No newline at end of file

.gitlab/issue_templates/Application - Archive.md

-## Summary
-
-Requesting this application be archived due to one of the following reasons:
-- [ ] Version is no longer supported by vendor
-- [ ] Application is End-Of-Life
-- [ ] License violation.
-- [ ] Other. See below.
-
-## Detailed Description
-
-(Please provide a detailed description of why this application should be archived)
-
-
-## Definition of Done
-- [ ] Application has been reviewed for archival
-- [ ] Project is officially marked as stale
-- [ ] Iron Bank frontend no longer lists application as available or approved
-
-
-
-
-
+## Summary
+
+Requesting this application be archived due to one of the following reasons:
+- [ ] Version is no longer supported by vendor
+- [ ] Application is End-Of-Life
+- [ ] License violation.
+- [ ] Other. See below.
+
+## Detailed Description
+
+(Please provide a detailed description of why this application should be archived)
+
+
+## Definition of Done
+- [ ] Application has been reviewed for archival
+- [ ] Project is officially marked as stale
+- [ ] Iron Bank frontend no longer lists application as available or approved
+
+
+
+
+
 /label ~"Container::Archive"
\ No newline at end of file

.gitlab/issue_templates/Application - Initial.md

-## Summary
-
-Requesting application to be hardened. This is only for initial hardening of a container.
-
-
-## Version Information
-
-Current version: (State the current version of the application as you see it)
-
-## Communication
-
-All communication should occur through this issue. This ensures that all information is documented in a centralized location and also ensures that all of the assignees are notified of updates. It is imperative that all required parties are listed as assignees of this issue and that individuals are not removed. Please do not remove anyone from the assignee list.
-
-If you need to contact the Container Hardening team, please identify your assigned point of contact. You can find your point of contact by:
-1. They should be listed as an assignee on this ticket
-2. They should be listed in the `hardening_manifest.yaml` file under the `maintainers` section with a field of `cht_member: true`
-
-If you have no assignee, feel free to tag Container Hardening leadership in your issue by commenting on this issue with your questions/concerns and then add `/cc @ironbank-notifications/leadership`. Gitlab will automatically notify all Container Hardening leadership to look at this issue and respond.
-
-
-## Responsibilities
-
-If this application is owned by a Contributor or Vendor (identifed as `Owner::Contributor` and `Owner::Vendor` respectively), then it is your responsibility to drive this issue through completion. This means that the Container Hardening team is not here to help push any deadlines/timeframes you may have with other customers or DoD agencies. If you have issues with the activity, you may notify Container Hardening leadership above. Do not change the ownership labels.
-
-
-## Definition of Done
-
-Hardening:
-- [ ] Hardening manifest is created and adheres to the schema (https://repo1.dsop.io/ironbank-tools/ironbank-pipeline/-/blob/master/schema/hardening_manifest.schema.json)
-- [ ] Container builds successfully through the Gitlab CI pipeline
-- [ ] Branch has been merged into `development`
-- [ ] Project is configured for automatic renovate updates (if possible)
-
-Justifications:
-- [ ] All findings have been justified per the above documentation
-- [ ] Justifications have been attached to this issue
-- [ ] Apply the label `Approval` to indicate this container is ready for the approval phase
-
-Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
-
-Approval Process (Container Hardening Team processes):
-- [ ] Peer review from Container Hardening Team
-- [ ] Findings Approver has reviewed and approved all justifications
-- [ ] Approval request has been sent to Authorizing Official
-- [ ] Approval request has been processed by Authorizing Official
-
-Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
-
-## Post Approval
-
-### Continuous Monitoring
-
-Once a container is approved, the `Approved` label will be applied to this issue and it will be closed. You will be able to find your applications on http://ironbank.dsop.io and https://registry1.dsop.io.
-
-In addition to the above, your application will now be subscribed to continuous monitoring. This means that any new findings discovered as part of this will need justifications. To satisfy this process, any new findings will trigger a new Gitlab issue in this project with the label `Container::New Findings`. All members listed in the `maintainers` section of the `hardening_manifest.yaml` file will automatically be assigned. It is your responsibility as a Contributor or Vendor to monitor for this and provide justifications in a timely fashion. This newly created issue will have all the instructions necessary to complete the process. Failure to provide justifications could result in the revocation of the application's approval status.
-
-### Updates
-
-It is imperative that application updates be submitted as quickly as possible. We do not want applications to become stale. To help with this process, Ironbank recommends using a tool called [Renovate](https://github.com/renovatebot/renovate). This requires a `renovate.json` file to be placed in your project and can automate the creation of issues and merge requests.
-
-If not using Renovate, it will be up to you as a Contributor or Vendor to keep this image up-to-date at all times. When you wish to submit an application update, you must create a new issue in this project using the `Application - Update` template and associate it with the corresponding merge request. If you submit a merge request alone, work will not proceed until a related issue is created. These issues are tracked using the label `Container::Update`.
-
-Additionally, it is imperative that all updates must be followed through to completion. Simply submitting an application update but not following through on justifications and approvals does not suffice and risk your application's approval status being revoked.
-
-### Bugs
-
-Occassionally, users may file bug reports for your application. It is your responsibility to monitor for these since they are created inside your project repository. Assignees will automatically be populated by the `members` section of the `hardening_manifest.yaml` file and will have the label `Bug`.
-
-
-
-
-
-
-
+## Summary
+
+Requesting application to be hardened. This is only for initial hardening of a container.
+
+
+## Version Information
+
+Current version: (State the current version of the application as you see it)
+
+## Communication
+
+All communication should occur through this issue. This ensures that all information is documented in a centralized location and also ensures that all of the assignees are notified of updates. It is imperative that all required parties are listed as assignees of this issue and that individuals are not removed. Please do not remove anyone from the assignee list.
+
+If you need to contact the Container Hardening team, please identify your assigned point of contact. You can find your point of contact by:
+1. They should be listed as an assignee on this ticket
+2. They should be listed in the `hardening_manifest.yaml` file under the `maintainers` section with a field of `cht_member: true`
+
+If you have no assignee, feel free to tag Container Hardening leadership in your issue by commenting on this issue with your questions/concerns and then add `/cc @ironbank-notifications/leadership`. Gitlab will automatically notify all Container Hardening leadership to look at this issue and respond.
+
+
+## Responsibilities
+
+If this application is owned by a Contributor or Vendor (identifed as `Owner::Contributor` and `Owner::Vendor` respectively), then it is your responsibility to drive this issue through completion. This means that the Container Hardening team is not here to help push any deadlines/timeframes you may have with other customers or DoD agencies. If you have issues with the activity, you may notify Container Hardening leadership above. Do not change the ownership labels.
+
+
+## Definition of Done
+
+Hardening:
+- [ ] Hardening manifest is created and adheres to the schema (https://repo1.dsop.io/ironbank-tools/ironbank-pipeline/-/blob/master/schema/hardening_manifest.schema.json)
+- [ ] Container builds successfully through the Gitlab CI pipeline
+- [ ] Branch has been merged into `development`
+- [ ] Project is configured for automatic renovate updates (if possible)
+
+Justifications:
+- [ ] All findings have been justified per the above documentation
+- [ ] Justifications have been attached to this issue
+- [ ] Apply the label `Approval` to indicate this container is ready for the approval phase
+
+Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
+
+Approval Process (Container Hardening Team processes):
+- [ ] Peer review from Container Hardening Team
+- [ ] Findings Approver has reviewed and approved all justifications
+- [ ] Approval request has been sent to Authorizing Official
+- [ ] Approval request has been processed by Authorizing Official
+
+Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
+
+## Post Approval
+
+### Continuous Monitoring
+
+Once a container is approved, the `Approved` label will be applied to this issue and it will be closed. You will be able to find your applications on http://ironbank.dsop.io and https://registry1.dsop.io.
+
+In addition to the above, your application will now be subscribed to continuous monitoring. This means that any new findings discovered as part of this will need justifications. To satisfy this process, any new findings will trigger a new Gitlab issue in this project with the label `Container::New Findings`. All members listed in the `maintainers` section of the `hardening_manifest.yaml` file will automatically be assigned. It is your responsibility as a Contributor or Vendor to monitor for this and provide justifications in a timely fashion. This newly created issue will have all the instructions necessary to complete the process. Failure to provide justifications could result in the revocation of the application's approval status.
+
+### Updates
+
+It is imperative that application updates be submitted as quickly as possible. We do not want applications to become stale. To help with this process, Ironbank recommends using a tool called [Renovate](https://github.com/renovatebot/renovate). This requires a `renovate.json` file to be placed in your project and can automate the creation of issues and merge requests.
+
+If not using Renovate, it will be up to you as a Contributor or Vendor to keep this image up-to-date at all times. When you wish to submit an application update, you must create a new issue in this project using the `Application - Update` template and associate it with the corresponding merge request. If you submit a merge request alone, work will not proceed until a related issue is created. These issues are tracked using the label `Container::Update`.
+
+Additionally, it is imperative that all updates must be followed through to completion. Simply submitting an application update but not following through on justifications and approvals does not suffice and risk your application's approval status being revoked.
+
+### Bugs
+
+Occassionally, users may file bug reports for your application. It is your responsibility to monitor for these since they are created inside your project repository. Assignees will automatically be populated by the `members` section of the `hardening_manifest.yaml` file and will have the label `Bug`.
+
+
+
+
+
+
+
 /label ~"Container::Initial"
\ No newline at end of file

.gitlab/issue_templates/Application - Update.md

-## Summary
-
-Requesting application be updated to a newer version.
-
-
-
-## Version Information
-
-Current version: (State the current version of the application as you see it)
-
-Updated version: (State the version you would like the application updated to)
-
-Under support: (Is the updated version within the same major version of the application or is this a new major version?)
-
-
-## Communication
-
-All communication should occur through this issue. This ensures that all information is documented in a centralized location and also ensures that all of the assignees are notified of updates. It is imperative that all required parties are listed as assignees of this issue and that individuals are not removed. Please do not remove anyone from the assignee list.
-
-If you need to contact the Container Hardening team, please identify your assigned point of contact. You can find your point of contact by:
-1. They should be listed as an assignee on this ticket
-2. They should be listed in the `hardening_manifest.yaml` file under the `maintainers` section with a field of `cht_member: true`
-
-If you have no assignee, feel free to tag Container Hardening leadership in your issue by commenting on this issue with your questions/concerns and then add `/cc @ironbank-notifications/leadership`. Gitlab will automatically notify all Container Hardening leadership to look at this issue and respond.
-
-
-## Responsibilities
-
-If this application is owned by a Contributor or Vendor (identifed as `Owner::Contributor` and `Owner::Vendor` respectively), then it is your responsibility to drive this issue through completion. This means that the Container Hardening team is not here to help push any deadlines/timeframes you may have with other customers or DoD agencies. If you have issues with the activity, you may notify Container Hardening leadership above. Do not change the ownership labels.
-
-
-## Definition of Done
-Hardening:
-- [ ] Hardening manifest has been updated and adheres to the schema (https://repo1.dsop.io/ironbank-tools/ironbank-pipeline/-/blob/master/schema/hardening_manifest.schema.json)
-- [ ] Container builds successfully throughthe Gitlab CI pipeline
-- [ ] Branch has been merged into `development`
-- [ ] Project is configured for automatic renovate updates (if possible)
-
-No new findings:
-- [ ] There are no new findings in this update. Skip the Justifications and Approval Process steps and apply the label `Approval`
-
-Justifications:
-- [ ] All findings have been justified per the above documentation
-- [ ] Justifications have been provided to the container hardening team
-- [ ] Skip the Justifications and Approval Process steps and apply the label `Approval`
-
-Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
-
-Approval Process:
-- [ ] Peer review from Container Hardening Team
-- [ ] Findings Approver has reviewed and approved all justifications
-- [ ] Approval request has been sent to Authorizing Official
-- [ ] Approval request has been processed by Authorizing Official
-
-Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
-
-
-## Post Approval
-
-### Continuous Monitoring
-
-Once a container is approved, the `Approved` label will be applied to this issue and it will be closed. You will be able to find your applications on http://ironbank.dsop.io and https://registry1.dsop.io.
-
-In addition to the above, your application will now be subscribed to continuous monitoring. This means that any new findings discovered as part of this will need justifications. To satisfy this process, any new findings will trigger a new Gitlab issue in this project with the label `Container::New Findings`. All members listed in the `maintainers` section of the `hardening_manifest.yaml` file will automatically be assigned. It is your responsibility as a Contributor or Vendor to monitor for this and provide justifications in a timely fashion. This newly created issue will have all the instructions necessary to complete the process. Failure to provide justifications could result in the revocation of the application's approval status.
-
-### Updates
-
-It is imperative that application updates be submitted as quickly as possible. We do not want applications to become stale. To help with this process, Ironbank recommends using a tool called [Renovate](https://github.com/renovatebot/renovate). This requires a `renovate.json` file to be placed in your project and can automate the creation of issues and merge requests.
-
-If not using Renovate, it will be up to you as a Contributor or Vendor to keep this image up-to-date at all times. When you wish to submit an application update, you must create a new issue in this project using the `Application - Update` template and associate it with the corresponding merge request. If you submit a merge request alone, work will not proceed until a related issue is created. These issues are tracked using the label `Container::Update`.
-
-Additionally, it is imperative that all updates must be followed through to completion. Simply submitting an application update but not following through on justifications and approvals does not suffice and risk your application's approval status being revoked.
-
-### Bugs
-
-Occassionally, users may file bug reports for your application. It is your responsibility to monitor for these since they are created inside your project repository. Assignees will automatically be populated by the `members` section of the `hardening_manifest.yaml` file and will have the label `Bug`.
-
-
-
-
-
+## Summary
+
+Requesting application be updated to a newer version.
+
+
+
+## Version Information
+
+Current version: (State the current version of the application as you see it)
+
+Updated version: (State the version you would like the application updated to)
+
+Under support: (Is the updated version within the same major version of the application or is this a new major version?)
+
+
+## Communication
+
+All communication should occur through this issue. This ensures that all information is documented in a centralized location and also ensures that all of the assignees are notified of updates. It is imperative that all required parties are listed as assignees of this issue and that individuals are not removed. Please do not remove anyone from the assignee list.
+
+If you need to contact the Container Hardening team, please identify your assigned point of contact. You can find your point of contact by:
+1. They should be listed as an assignee on this ticket
+2. They should be listed in the `hardening_manifest.yaml` file under the `maintainers` section with a field of `cht_member: true`
+
+If you have no assignee, feel free to tag Container Hardening leadership in your issue by commenting on this issue with your questions/concerns and then add `/cc @ironbank-notifications/leadership`. Gitlab will automatically notify all Container Hardening leadership to look at this issue and respond.
+
+
+## Responsibilities
+
+If this application is owned by a Contributor or Vendor (identifed as `Owner::Contributor` and `Owner::Vendor` respectively), then it is your responsibility to drive this issue through completion. This means that the Container Hardening team is not here to help push any deadlines/timeframes you may have with other customers or DoD agencies. If you have issues with the activity, you may notify Container Hardening leadership above. Do not change the ownership labels.
+
+
+## Definition of Done
+Hardening:
+- [ ] Hardening manifest has been updated and adheres to the schema (https://repo1.dsop.io/ironbank-tools/ironbank-pipeline/-/blob/master/schema/hardening_manifest.schema.json)
+- [ ] Container builds successfully throughthe Gitlab CI pipeline
+- [ ] Branch has been merged into `development`
+- [ ] Project is configured for automatic renovate updates (if possible)
+
+No new findings:
+- [ ] There are no new findings in this update. Skip the Justifications and Approval Process steps and apply the label `Approval`
+
+Justifications:
+- [ ] All findings have been justified per the above documentation
+- [ ] Justifications have been provided to the container hardening team
+- [ ] Skip the Justifications and Approval Process steps and apply the label `Approval`
+
+Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
+
+Approval Process:
+- [ ] Peer review from Container Hardening Team
+- [ ] Findings Approver has reviewed and approved all justifications
+- [ ] Approval request has been sent to Authorizing Official
+- [ ] Approval request has been processed by Authorizing Official
+
+Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
+
+
+## Post Approval
+
+### Continuous Monitoring
+
+Once a container is approved, the `Approved` label will be applied to this issue and it will be closed. You will be able to find your applications on http://ironbank.dsop.io and https://registry1.dsop.io.
+
+In addition to the above, your application will now be subscribed to continuous monitoring. This means that any new findings discovered as part of this will need justifications. To satisfy this process, any new findings will trigger a new Gitlab issue in this project with the label `Container::New Findings`. All members listed in the `maintainers` section of the `hardening_manifest.yaml` file will automatically be assigned. It is your responsibility as a Contributor or Vendor to monitor for this and provide justifications in a timely fashion. This newly created issue will have all the instructions necessary to complete the process. Failure to provide justifications could result in the revocation of the application's approval status.
+
+### Updates
+
+It is imperative that application updates be submitted as quickly as possible. We do not want applications to become stale. To help with this process, Ironbank recommends using a tool called [Renovate](https://github.com/renovatebot/renovate). This requires a `renovate.json` file to be placed in your project and can automate the creation of issues and merge requests.
+
+If not using Renovate, it will be up to you as a Contributor or Vendor to keep this image up-to-date at all times. When you wish to submit an application update, you must create a new issue in this project using the `Application - Update` template and associate it with the corresponding merge request. If you submit a merge request alone, work will not proceed until a related issue is created. These issues are tracked using the label `Container::Update`.
+
+Additionally, it is imperative that all updates must be followed through to completion. Simply submitting an application update but not following through on justifications and approvals does not suffice and risk your application's approval status being revoked.
+
+### Bugs
+
+Occassionally, users may file bug reports for your application. It is your responsibility to monitor for these since they are created inside your project repository. Assignees will automatically be populated by the `members` section of the `hardening_manifest.yaml` file and will have the label `Bug`.
+
+
+
+
+
 /label ~"Container::Update"
\ No newline at end of file

.gitlab/issue_templates/Bug.md

-## Summary
-
-(Summarize the bug encountered concisely)
-
-
-## Steps to reproduce
-
-(How one can reproduce the issue - this is very important)
-
-
-## What is the current bug behavior?
-
-(What actually happens)
-
-
-## What is the expected correct behavior?
-
-(What you should see instead)
-
-
-## Relevant logs and/or screenshots
-
-(Paste any relevant logs - please use code blocks (```) to format console output,
-logs, and code as it's very hard to read otherwise.)
-
-
-## Possible fixes
-
-(If you can, link to the line of code that might be responsible for the problem)
-
-
-## Defintion of Done
-- [ ] Bug has been identified and corrected within the container
-
-
-
-
-
-
-
+## Summary
+
+(Summarize the bug encountered concisely)
+
+
+## Steps to reproduce
+
+(How one can reproduce the issue - this is very important)
+
+
+## What is the current bug behavior?
+
+(What actually happens)
+
+
+## What is the expected correct behavior?
+
+(What you should see instead)
+
+
+## Relevant logs and/or screenshots
+
+(Paste any relevant logs - please use code blocks (```) to format console output,
+logs, and code as it's very hard to read otherwise.)
+
+
+## Possible fixes
+
+(If you can, link to the line of code that might be responsible for the problem)
+
+
+## Defintion of Done
+- [ ] Bug has been identified and corrected within the container
+
+
+
+
+
+
+
 /label ~Bug
\ No newline at end of file

.gitlab/issue_templates/Feature Request.md

-## Feature description
-
-(Detailed description of the feature being requested)
-
-
-## Use cases
-
-
-(Detailed description of the use case for this feature)
-
-
-## Benefits
-
-(How does this benefit others)
-
-
-## Requirements
-
-(Any requirements for this feature to be enabled?)
-
-
-## Links / references
-
-(List of links or references that support this feature)
-
-
-## Definition of Done
-- [ ] Feature has been implemented
-
-
-
-
-
-
-
+## Feature description
+
+(Detailed description of the feature being requested)
+
+
+## Use cases
+
+
+(Detailed description of the use case for this feature)
+
+
+## Benefits
+
+(How does this benefit others)
+
+
+## Requirements
+
+(Any requirements for this feature to be enabled?)
+
+
+## Links / references
+
+(List of links or references that support this feature)
+
+
+## Definition of Done
+- [ ] Feature has been implemented
+
+
+
+
+
+
+
 /label ~Feature
\ No newline at end of file

.gitlab/issue_templates/Leadership Question.md

-## Leadership question
-
-(Detailed description of the question you'd like to ask the leadership team)
-
-
-
-
-
-
-
-/label ~"Question::Leadership" ~"To Do"
+## Leadership question
+
+(Detailed description of the question you'd like to ask the leadership team)
+
+
+
+
+
+
+
+/label ~"Question::Leadership" ~"To Do"
 /cc @ironbank-notifications/leadership
\ No newline at end of file

.gitlab/issue_templates/New Findings.md

-## Summary
-
-Container has new findings discovered during continuous monitoring.
-
-
-
-## Definition of Done
-Justifications:
-- [ ] All findings have been justified
-- [ ] Justifications have been provided to the container hardening team
-- [ ] `Approval` label has been applied
-
-Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
-
-Approval Process:
-- [ ] Findings Approver has reviewed and approved all justifications
-- [ ] Approval request has been sent to Authorizing Official
-- [ ] Approval request has been processed by Authorizing Official
-
-Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
-
-
-
-
-
-
+## Summary
+
+Container has new findings discovered during continuous monitoring.
+
+
+
+## Definition of Done
+Justifications:
+- [ ] All findings have been justified
+- [ ] Justifications have been provided to the container hardening team
+- [ ] `Approval` label has been applied
+
+Note: The justifications must be provided in a timely fashion. Failure to do so could result in new findings being identified which may start this process over.
+
+Approval Process:
+- [ ] Findings Approver has reviewed and approved all justifications
+- [ ] Approval request has been sent to Authorizing Official
+- [ ] Approval request has been processed by Authorizing Official
+
+Note: If the above approval process is kicked back for any reason, the `Approval` label will be removed and the issue will be sent back to `Open`. Any comments will be listed in this issue for you to address. Once they have been addressed, you may re-add the `Approval` label.
+
+
+
+
+
+
 /label ~"Container::New Findings"
\ No newline at end of file

.gitlab/issue_templates/Onboarding Question.md

-## Onboarding question
-
-(Detailed description of the question you'd like to ask the onboarding team)
-
-
-
-
-
-
-
-/label ~"Question::Onboarding" ~"To Do"
+## Onboarding question
+
+(Detailed description of the question you'd like to ask the onboarding team)
+
+
+
+
+
+
+
+/label ~"Question::Onboarding" ~"To Do"
 /cc @ironbank-notifications/onboarding
\ No newline at end of file

.gitlab/issue_templates/Pipeline Failure.md

-## Summary
-
-(Summarize the pipeline issue encountered concisely)
-
-
-## Link to failed pipeline
-
-(Link to the failed pipeline)
-
-
-## What is the current bug behavior?
-
-(What actually happens)
-
-
-## What is the expected correct behavior?
-
-(What you should see instead)
-
-
-## Possible fixes
-
-(If you can, link to the line of code that might be responsible for the problem)
-
-
-## Definition of Done
-- [ ] Pipeline failure has been resolved
-
-
-
-
-
-
-
-
+## Summary
+
+(Summarize the pipeline issue encountered concisely)
+
+
+## Link to failed pipeline
+
+(Link to the failed pipeline)
+
+
+## What is the current bug behavior?
+
+(What actually happens)
+
+
+## What is the expected correct behavior?
+
+(What you should see instead)
+
+
+## Possible fixes
+
+(If you can, link to the line of code that might be responsible for the problem)
+
+
+## Definition of Done
+- [ ] Pipeline failure has been resolved
+
+
+
+
+
+
+
+
 /label ~Pipeline
\ No newline at end of file

Dockerfile

+ARG BASE_REGISTRY=registry1.dsop.mil
+ARG BASE_IMAGE=redhat/ubi/ubi8
+ARG BASE_TAG=8.3
+
+FROM ${BASE_REGISTRY}/${BASE_IMAGE}:${BASE_TAG}
+
+ARG VERSION=1.2.1
+
+
+ARG USERNAME=benjo
+ARG GROUPNAME=benjo
+
+ARG UID=1000
+ARG GID=1000
+
+USER root
+WORKDIR /tmp
+
+COPY \
+  LICENSE \
+  README.md \
+  courseware-editor.tar.gz \
+  config/appsettings.json \
+  config/config.json \
+  dumb-init \
+  scripts/start.sh \
+  ./
+
+RUN groupadd --gid $GID $GROUPNAME && \
+      useradd --uid $UID --gid $GID $USERNAME && \
+      yum install -y libicu curl && \
+      yum clean all && \
+      rm -rf /var/cache/dnf && \
+      tar -zxf courseware-editor.tar.gz && \
+      chown -R $UID:$GID /tmp/* && \
+      chmod 755 dumb-init start.sh && \
+      mv courseware-editor /courseware-editor && \
+      mv config.json /courseware-editor && \
+      mv start.sh /courseware-editor && \
+      mv dumb-init /usr/local/bin && \
+      mv LICENSE README.md /courseware-editor && \
+      rm -rf ./*
+
+WORKDIR /courseware-editor
+
+ENV WORKSPACE_PATH=/modules
+
+USER $UID:$GID
+
+EXPOSE 1337
+
+HEALTHCHECK --interval=12s --timeout=10s --start-period=30s \
+  CMD curl --fail http://localhost/api/v1/heartbeat || exit 1
+
+ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
+
+WORKDIR /courseware-editor/server
+
+CMD ["/courseware-editor/start.sh"]

LICENSE

+The Beast Core application is developed by Beast Code to support the
+qualification and maintenance performance and logistical pipelines of military
+personnel, in accordance with DOD's requirements. Beast Core currently
+supports several platforms, including the DDG 1000, DDG 51, Columbia and
+Virginia classes, Bronco II aircraft, and is in the process of being adopted by
+the Navy Enterprise (NAVSEA and NAVAIR).
+
+The core functionality of Beast Core is a "digital twin". Each twin is
+comprised of a 3D representation of the platform's systems (e.g., fuel,
+hydraulic, electrical, etc.), linked meta-data and associated technical
+documentation to equipment/components, and a functional model simulating
+equipment behavior that look and act like the real-life platform. The
+application utilizes a digital twin to enhance engineers, operators, and
+maintainers familiarization, qualification, and operation of systems vital to
+the platform's mission. The same model will support the performance of the
+users' proficiency/qualification training and maintenance tasks. In addition,
+the linkage to internal and external metadata makes it a perfect for use as a
+logistical tool.
+
+Beast Core is web-based technology that can be deployed to an existing server
+infrastructure and run on PCs, laptops and other assets connected to the
+network. The software can also operate on a tablet or mobile device
+(disconnected from the network) allowing users to utilize the digital twin
+anytime, anywhere. Additionally, Beast Core is touchscreen friendly and works
+with a gaming controller to enable an intuitive user interface.
+
+Beast Core licensing and pricing is flexible and supports various
+organizational requirements from a single user up to large scale enterprise
+deployments. Additionally, purchasing a license gives the user access to one
+year of software updates and tech support.
+
+For more information on Beast Core licensing and pricing options please contact
+us at:
+Email: info@Beast-Code.com
+Phone: (850) 702-3600
+Website: https://www.beast-code.com/

README.md

-# <application name>
+# Courseware-Editor
 
-Project template for all Iron Bank container repositories.
+The Courseware-Editor application is developed by Beast Code to support the
\ No newline at end of file
+qualification and maintenance performance and logistical pipelines of military
+personnel, in accordance with DOD's requirements. Courseware-Editor currently
+supports several platforms, including the DDG 1000, DDG 51, Columbia and
+Virginia classes, Bronco II aircraft, and is in the process of being adopted by
+the Navy Enterprise (NAVSEA and NAVAIR).
+
+The core functionality of Courseware-Editor is a "digital twin". Each twin is
+comprised of a 3D representation of the platform's systems (e.g., fuel,
+hydraulic, electrical, etc.), linked meta-data and associated technical
+documentation to equipment/components, and a functional model simulating
+equipment behavior that look and act like the real-life platform. The
+application utilizes a digital twin to enhance engineers, operators, and
+maintainers familiarization, qualification, and operation of systems vital to
+the platform's mission. The same model will support the performance of the
+users' proficiency/qualification training and maintenance tasks. In addition,
+the linkage to internal and external metadata makes it a perfect for use as a
+logistical tool.
+
+Courseware-Editor is web-based technology that can be deployed to an existing server
+infrastructure and run on PCs, laptops and other assets connected to the
+network. The software can also operate on a tablet or mobile device
+(disconnected from the network) allowing users to utilize the digital twin
+anytime, anywhere. Additionally, Courseware-Editor is touchscreen friendly and works
+with a gaming controller to enable an intuitive user interface.
+
+Courseware-Editor licensing and pricing is flexible and supports various
+organizational requirements from a single user up to large scale enterprise
+deployments. Additionally, purchasing a license gives the user access to one
+year of software updates and tech support.
+
+For more information on Courseware-Editor licensing and pricing options please contact
+us at:
+Email: info@Beast-Code.com
+Phone: (850) 702-3600
+Website: https://www.beast-code.com/
+
+**Container Requirements**
+---
+
+**Software Requirements**: Google Chrome Web Browser
+
+**Memory Requirements**: The minimum memory requirement is 2GBs RAM.
+Recommended: 8-16GB RAM.
+
+**CPU Requirements**: Recommended minimum 2.4GHz Intel Core i5-6300U or
+equivalent.
+
+**Disk Requirements**: Application <100MB, Fully-Developed Digital Twin > 20GB
+
+**Storage volume Requirements**: Courseware-Editor may either be bundled with a
+Digital Twin or can support Digital Twins hosted on volumes.  The configuration
+is dependent upon our customer's environment and use case.
+
+**Other Client Hardware Requirements**: For optimal performance, it is
+suggested that client systems accessing Courseware-Editor have a NVIDIA GeForce GTX
+1060 video card or equivalent.
+
+NOTE: This Courseware-Editor container does NOT come bundled with a Digital Twin and
+will not be fully functional as a standalone application.

config/appsettings.json

+{
+  "Logging": {
+    "LogLevel": {
+      "Default": "Information",
+      "Microsoft": "Warning",
+      "Microsoft.Hosting.Lifetime": "Information"
+    }
+  },
+  "AllowedHosts": "*"
+}

config/appsettings.production.json

+{
+  "urls": "http://*:8080",
+  "WWWroot": "../courseware-editor-client",
+  "workspaceRoot": "../workspaces",
+  "workspace": "uss-never-sleeps"
+}

config/config.json

+{
+  "viewerColor": {
+    "r": 0,
+    "g": 0,
+    "b": 0.2
+  },
+  "selectionShader": {
+    "type": "Kerbal"
+  },
+  "startingApp": {
+    "name": "3D Viewer"
+  }
+}

hardening_manifest.yaml

+---
+apiVersion: v1
+
+# The repository name in registry1, excluding /ironbank/
+name: "beast-code/courseware-editor/base-image"
+
+# List of tags to push for the repository in registry1
+# The most specific version should be the first tag and will be shown
+# on ironbank.dsop.io
+tags:
+- "1.2.1"
+- "latest"
+
+# Build args passed to Dockerfile ARGs
+args:
+  BASE_IMAGE: "redhat/ubi/ubi8"
+  BASE_TAG: "8.3"
+
+# Docker image labels
+labels:
+  org.opencontainers.image.title: "base-image"
+  ## Human-readable description of the software packaged in the image
+  org.opencontainers.image.description: "Beast Core renders digital twins (3D representations) of ships, aircraft, etc."
+  ## License(s) under which contained software is distributed
+  org.opencontainers.image.licenses: "Contact info@Beast-Code.com"
+  ## URL to find more information on the image
+  org.opencontainers.image.url: "https://beast-code.com/products/courseware-editor"
+  ## Name of the distributing entity, organization or individual
+  org.opencontainers.image.vendor: "Beast Code, LLC"
+  org.opencontainers.image.version: "1.2.1"
+  ## Keywords to help with search (ex. "cicd,gitops,golang")
+  mil.dso.ironbank.image.keywords: "digital twin, 3D"
+  ## This value can be "opensource" or "commercial"
+  mil.dso.ironbank.image.type: "commercial"
+  ## Product the image belongs to for grouping multiple images
+  mil.dso.ironbank.product.name: "courseware-editor"
+
+# List of resources to make available to the offline build context
+resources:
+- auth:
+    id: beast
+    region: us-east-2
+  filename: courseware-editor.tar.gz
+  url: s3://beast-code.core/courseware-editor.tar.gz
+  validation:
+    type: sha256
+    value: 2f1d508b394e4fb081939bc9de2d8aa7ae1cd30f584f81d4fe6eae2e572cc966
+- auth:
+    id: beast
+    region: us-east-2
+  filename: dumb-init
+  url: s3://beast-code.core/dumb-init
+  validation:
+    type: sha256
+    value: 37f2c1f0372a45554f1b89924fbb134fc24c3756efaedf11e07f599494e0eff9
+
+# List of project maintainers
+maintainers:
+- name: "Daniel Dolfie"
+  username: "ddolfie"
+  email: "daniel.dolfie@beast-code.com"
+- name: "Brandon Sumner"
+  username: "bsumner"
+  email: "brandon.sumner@beast-code.com" 
+- name: "Matthew Stover"
+  username: "mstover"
+  email: "matthew.stover@beast-code.com"
+#   cht_member: true # FIXME: Uncomment if the maintainer is a member of CHT
+# - name: "FIXME"
+#   username: "FIXME"
+#   email: "FIXME"

scripts/start.sh

+#!/bin/sh
+
+rm -rf "$WORKPACE_PATH/lost+found"
+
+/courseware-editor/server/BCServer.Server \
+  --WWWRoot /courseware-editor/courseware-editor-client \
+  --deployment /courseware-editor/config.json \
+  --urls "http://*:$PORT" \
+  --workspaceRoot $WORKSPACE_PATH