Merge branch 'development' into 'master'

Development

See merge request !5

.gitignore

+# Tarball
+*.tar.gz
+
+# RPM
+*.rpm
+
+# Scripts
+download-tar-files.sh
+build-container-image.sh
+send-merge-request-to-gitlab.sh
\ No newline at end of file

.gitlab/issue_templates/Access Request.md

@@ -13,7 +13,4 @@ The access level should be:
 - [ ] All accounts have been provided the necessary accesses
 
 
-
-
-
 /label ~"Access" ~"To Do"
\ No newline at end of file

.gitlab/issue_templates/Application - Archive.md

@@ -17,7 +17,4 @@ Requesting this application be archived due to one of the following reasons:
 - [ ] 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

@@ -7,69 +7,25 @@ Requesting application to be hardened. This is only for initial hardening of a c
 
 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.
+Under support: (Is the updated version within the same major version of the application or is this a new major version?)
 
 
 ## 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
+- [ ] Container builds successfully
+- [ ] Greylist file has been created (requires a member from container hardening)
 - [ ] 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.
+- [ ] Justifications have been provided to the container hardening team
 
-Approval Process (Container Hardening Team processes):
+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

@@ -13,38 +13,18 @@ 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
+- [ ] Container builds successfully
+- [ ] Container version has been updated in greylist file
 - [ ] 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`
+- [ ] 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
@@ -52,31 +32,6 @@ Approval Process:
 - [ ] 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

@@ -33,9 +33,4 @@ logs, and code as it's very hard to read otherwise.)
 - [ ] Bug has been identified and corrected within the container
 
 
-
-
-
-
-
 /label ~Bug
\ No newline at end of file

.gitlab/issue_templates/Feature Request.md

@@ -28,9 +28,4 @@
 - [ ] Feature has been implemented
 
 
-
-
-
-
-
 /label ~Feature
\ No newline at end of file

.gitlab/issue_templates/Leadership Question.md

@@ -3,10 +3,5 @@
 (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

@@ -8,20 +8,12 @@ Container has new findings discovered during continuous monitoring.
 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

@@ -3,10 +3,5 @@
 (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

@@ -27,10 +27,4 @@
 - [ ] Pipeline failure has been resolved
 
 
-
-
-
-
-
-
 /label ~Pipeline
\ No newline at end of file

Dockerfile

+# These three ARGs must point to an Iron Bank image - the BASE_REGISTRY should always be what is written below; please use
+# '--build-arg' when building locally to replace these values.
+#
+ARG BASE_REGISTRY=registry1.dsop.io
+ARG BASE_IMAGE=redhat/ubi/ubi8
+ARG BASE_TAG=8.3
+
+# FROM statement must reference the base image using the three ARGs established.
+#
+FROM ${BASE_REGISTRY}/${BASE_IMAGE}:${BASE_TAG}
+
+MAINTAINER dpgswdist@microsoft.com
+
+EXPOSE 1433
+
+ENV MSSQL_RPC_PORT=135
+
+# Required variables for consuming the tarball with
+# the "install" directory.
+#
+ARG INSTALL_DIRECTORY=install
+ARG INSTALL_DIRECTORY_TARBALL=$INSTALL_DIRECTORY.tar.gz
+
+# Consume the "install" directory.
+#
+# 1. Copy the tarball into the container's root directory ('/').
+# 2. Extract into the container's root directory the directory
+#    inside the tarball.
+# 3. Delete the tarball.
+# 4. Set root as the owner of the directory obtained in step #2.
+# 5. Copy the contents of the directory obtained in step #2 into the
+#    container's root directory.
+# 6. Delete the directory obtained in step #2.
+# 7. Make /opt/mssql/bin/ executable, so binaries under opt/mssql/bin/
+#    can be run.
+#
+COPY ./$INSTALL_DIRECTORY_TARBALL /
+RUN tar -C / -zxf /$INSTALL_DIRECTORY_TARBALL && \
+    rm -f $INSTALL_DIRECTORY_TARBALL && \
+    chown root:root -R /$INSTALL_DIRECTORY/ && \
+    cp -frp /$INSTALL_DIRECTORY/* / && \
+    rm -rf /$INSTALL_DIRECTORY && \
+    chmod +x -R /opt/mssql/bin/
+
+# Required variables for consuming the tarball with
+# the directory containing RHEL 8 RPMs which do not
+# come from the UBI and their corresponding GPG keys.
+#
+ARG RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY=rpms
+ARG RHEL8_RPM_FILES_NOT_FROM_UBI_TARBALL=$RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY.tar.gz
+ARG RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY_PATH=/tmp/$RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY
+
+# Consume the directory with the RHEL 8 RPM files.
+#
+# 1. Copy the tarball into the container's /tmp directory.
+# 2. Extract into the container's /tmp directory the directory
+#    inside the tarball.
+# 3. Delete the tarball.
+# 4. Set root as the owner of the directory obtained in step #2.
+#
+# Note: the /tmp directory is deleted in install_external.sh.
+#
+COPY ./$RHEL8_RPM_FILES_NOT_FROM_UBI_TARBALL /tmp
+RUN tar -C /tmp -zxf /tmp/$RHEL8_RPM_FILES_NOT_FROM_UBI_TARBALL && \
+    rm -f /tmp/$RHEL8_RPM_FILES_NOT_FROM_UBI_TARBALL && \
+    chown root:root -R $RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY_PATH
+
+# Variables to be used as parameters to install_external.sh
+#
+ARG PLATFORM_NAME=rhel8
+ARG PLATFORM_FLAVOR_NAME=dsop
+ARG BUILD_ENVIRONMENT=external
+
+# Parameters to install_external.sh:
+# 1. Platform name
+# 2. Platform flavor name
+# 3. Build environment
+# 4. Path to directory with non-base-OS-image RPM
+# files and GPG keys
+#
+# Run install_external.sh to install dependencies and make
+# some configurations.
+#
+COPY scripts/install_external.sh /tmp/install_external.sh
+RUN chmod +x /tmp/install_external.sh && \
+    /tmp/install_external.sh $PLATFORM_NAME $PLATFORM_FLAVOR_NAME $BUILD_ENVIRONMENT $RHEL8_RPM_FILES_NOT_FROM_UBI_DIRECTORY_PATH
+
+COPY scripts/healthcheck.sh /healthcheck.sh
+RUN chmod +x /healthcheck.sh
+
+HEALTHCHECK \
+    --start-period=180s \
+    --interval=180s \
+    --timeout=10s \
+    --retries=5 \
+    CMD /healthcheck.sh
+
+# Copy permissions_check_external.sh and change its mode before
+# switching to the non-root user.
+#
+COPY scripts/permissions_check_external.sh /opt/mssql/bin/permissions_check_external.sh
+RUN chmod +x /opt/mssql/bin/permissions_check_external.sh
+
+# Switch to non-root user.
+#
+USER mssql
+ENTRYPOINT ["/opt/mssql/bin/permissions_check_external.sh"]
+
+CMD ["/opt/mssql/bin/sqlservr"]
+

LICENSE

+See the SQL Server license files under the "licenses/" directory.

README.md

-# microsoft-sql-server-2019
+# SQL Server 2019 on Red Hat Enterprise Linux 8
 
-microsoft sql-server-2019
\ No newline at end of file
+# Prerequisites
+- Minimum of 2 GB of disk space.
+- Minimum of 2 GB of RAM.
+- [System requirements for SQL Server on Linux.](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15#system)
+
+## 1. Run the container
+
+To run the container image with Podman, you can use the following command from a bash shell
+
+```
+podman run \
+-e "ACCEPT_EULA=Y" \
+<provide the MSSQL_SA_PASSWORD environment variable definition here> \
+-p 1433:1433 --name <provide the container name here (e.g. "sql1")> \
+-d registry1.dsop.io/microsoft/sql-server:2019-CU8-rhel8
+```
+
+NOTE: besides the ```"ACCEPT_EULA=Y"``` environment variable, you must also provide to the container the ```"MSSQL_SA_PASSWORD"``` environment variable containing the password that you want to set for the system administrator (sa) account.
+
+## 2. Change the SA password
+
+The SA account is a system administrator on the SQL Server instance that gets created during setup. After creating your SQL Server container, the ```MSSQL_SA_PASSWORD``` environment variable you specified is discoverable by running ```echo $MSSQL_SA_PASSWORD``` in the container. For security purposes, change your SA password.
+
+```
+podman exec -it \
+    <provide the container name here (e.g. "sql1")> \
+    /opt/mssql-tools/bin/sqlcmd \
+   -S localhost -U SA -P <provide the current password here surrounded by double quotes> \
+   -Q 'ALTER LOGIN SA WITH PASSWORD=<provide the new password here surrounded by double quotes>'
+```
+
+## 3. Connect to SQL Server
+### 3.1 Connect from inside the container
+
+The following steps use the SQL Server command-line tool, sqlcmd, inside the container to connect to SQL Server.
+
+```
+podman exec -it <provide the container name here (e.g. "sql1")> "bash"
+```
+```
+/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P <provide the password here surrounded by double quotes>
+```
+
+### 3.2 Connect from outside the container
+
+You can also connect to the SQL Server instance from any external Linux, Windows, or macOS tool that supports SQL connections.
+
+The following steps use sqlcmd outside of your container to connect to SQL Server running in the container. These steps assume that you already have the SQL Server command-line tools installed outside of your container. The same principles apply when using other tools, but the process of connecting is unique to each tool.
+
+1. Find the IP address for the machine that hosts your container. On Linux, use ```ifconfig``` or ```ip addr```. On Windows, use ```ipconfig```.
+
+2. For this example, install the sqlcmd tool on your client machine. For more information, see [Install sqlcmd on Windows](https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15) or [Install sqlcmd on Linux](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-tools?view=sql-server-ver15).
+
+3. Run sqlcmd specifying the IP address and the port mapped to port 1433 in your container. In this example, that is the same port, 1433, on the host machine. If you specified a different mapped port on the host machine, you would use it here.
+
+    ```
+    sqlcmd -S <ip_address>,1433 -U SA -P <provide the new password here surrounded by double quotes>
+    ```
+
+4. Run Transact-SQL commands. When finished, type ```QUIT```.
+
+Other common tools to connect to SQL Server include:
+
+- [Visual Studio Code](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-develop-use-vscode?view=sql-server-ver15)
+- [SQL Server Management Studio (SSMS) on Windows](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-manage-ssms?view=sql-server-ver15)
+- [Azure Data Studio](https://docs.microsoft.com/en-us/sql/azure-data-studio/what-is?view=sql-server-ver15)
+- [mssql-cli (Preview)](https://github.com/dbcli/mssql-cli/blob/master/doc/usage_guide.md)
+- [PowerShell Core](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-manage-powershell-core?view=sql-server-ver15)
+
+## 4. Container Healthcheck
+
+The health check of the container relies on the SQL Server Extended Events technology. What the logic of the health check does is look for updates in system health files of an Extended Events session that is created by default when the container is executed. Given the latter, this Extended Events session must not be stopped and the location of the system health files must not be changed. The health check does, however, check for those system health files in two possible locations:
+
+- The default location at ```/var/opt/mssql/log```.
+- The parent directory of the file whose path can be configured by the ```MSSQL_ERROR_LOG_FILE``` environment variable. By default, system health files are always placed next to SQL Server error log files.
+
+See [SQL Docs - Extended Events Overview](https://docs.microsoft.com/en-us/sql/relational-databases/extended-events/extended-events?view=sql-server-ver15) and [SQL Docs - Configure SQL Server settings with environment variables on Linux](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-environment-variables?view=sql-server-ver15).
+
+<br>
+
+See the full documentation of SQL Server containers on [SQL Docs - Quickstart: Run SQL Server container images with Docker](https://docs.microsoft.com/en-us/sql/linux/quickstart-install-connect-docker?view=sql-server-ver15&pivots=cs1-bash).
\ No newline at end of file

clamav-whitelist

+Multios.Trojan.ElectroRAT-9823393-0

hardening_manifest.yaml

+---
+apiVersion: v1
+
+# The repository name in registry1, excluding /ironbank/
+name: "microsoft/microsoft/microsoft-sql-server-2019-rhel8"
+
+# 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.dso.mil
+tags:
+- "2019-CU8-rhel-8"
+- "latest"
+
+# Build args passed to Dockerfile ARGs
+args:
+  BASE_IMAGE: "redhat/ubi/ubi8"
+  BASE_TAG: "8.3"
+
+# Docker image labels
+labels:
+  # Name of the image
+  org.opencontainers.image.title: "microsoft-sql-server-2019-rhel8"
+  # Human-readable description of the software packaged in the image
+  org.opencontainers.image.description: "SQL Server 2019 on RHEL8 Image"
+  # License(s) under which contained software is distributed
+  org.opencontainers.image.licenses: "Developer, Enterprise Core, Enterprise, Evaluation, Express, Standard, Web"
+  # URL to find more information on the image
+  org.opencontainers.image.url: "https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-docker-container-deployment"
+  # Name of the distributing entity, organization or individual
+  org.opencontainers.image.vendor: "Microsoft Corporation"
+  # Authoritative version of the software
+  org.opencontainers.image.version: "2019-CU8-rhel-8"
+  # Keywords to help with search (ex. "cicd,gitops,golang")
+  mil.dso.ironbank.image.keywords: "database,db,sql,relational database,container,analytics,storage,security"
+  # 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: "microsoft/microsoft"
+
+# List of resources to make available to the offline build context
+resources:
+  - url: "https://hlspubdist.blob.core.windows.net/15d0d4073d23-4/mssql-server-2019-cu8/15.0.4073.23-4/rhel8-dsop/rpms.tar.gz"
+    filename: "rpms.tar.gz" # [required field] desired staging name for the build context
+    validation:
+      type: "sha512" # supported: sha256, sha512
+      value: "77d2f69325f18be43eceb5064f4836515c19dc58d94f9fe2d4fd113e76dc114dedbae6d453b38bde811d551a20d0f1aaff19ae68ccde51f2778002c867871287" # must be lowercase
+  - url: "https://hlspubdist.blob.core.windows.net/15d0d4073d23-4/mssql-server-2019-cu8/15.0.4073.23-4/rhel8-dsop/install.tar.gz"
+    filename: "install.tar.gz"
+    validation:
+      type: "sha512"
+      value: "6e0d5030711e87d1e1c591100316e3bb810cd5d51a139c9d5a69476bd701f0107b6bf869728480e9d14c0b49eddfb72882cd3f2dcb70dfbe1e6619f46c35d593"
+    # if the file you pull is from a github repo, make sure this is the official repo for that file,
+    # and indicate that in a comment in this file
+
+# List of project maintainers
+maintainers:
+- email: "saorozco@microsoft.com"
+  # The name of the current container owner
+  name: "Salvador Orozco Villalever"
+  # The gitlab username of the current container owner
+  username: "saorozco_msft"
+  cht_member: false # NOTE: Include if the maintainer is a member of CHT