Onboarding Services

This is a list of the different services the Customer Services and Onboarding team (CSO) provides to users within Iron Bank.

These are the different issues templates that can be used. Use this link to request any of these services. (continuously growing):

When requesting any of these services please ensure to use the corresponding issue template in repo1.

Access requests are for users needing development access to a specific project or group within repo1.

Once an issue is opened in dccscr or the relating project a CSO member will review.
If the issue is not opened by a current maintainer/developer of the project then we need approval from one before adding the new user. (this would mean adding one from the hardening manifest to the issue)
Once approval is given developer access is granted.

Projects that are no longer maintained by the Contributor/Vendor or products that are now EOL upstream are archived in repo1.

If a team or maintainer no longer supports a project in repo1. They can open an issue in dccscr or in the corresponding project for Iron bank to archive it. Or if the archival label has been added to an open issue. The Onboarding team will then investigate.
Once notification has been given to the onboarding team to archive a project.
- We will ensure the project is no longer maintained/supported by the listed maintainers in the hardening manifest.
- Then in VAT, that project is marked as either "Archived" or "EOL" dependant upon the state of the project.
- Status is verified from Iron Bank's Front End IBFE that the container has been updated to reflect changes made in VAT.
- All open issues in the corresponding project in repo1 are then closed.
- The project is then Archived in repo1.
- (Projects that have been archived are not lost nor removed from our image registry. This is for maintenance control and frees up the pipelines as the projects are no longer continuously scanned. If a project has been Archived that should not have been or a new team is going to take over maintenance of the project. An issue in dccscr can be opened up.)

This issue template is used when new projects are created in repo1 and the initial hardening of the project is underway.

Firstly a Contributor or Vendor must submit a new onboarding request. The Onboarding team will review the request and approve or reach back out to the primary engineers and POC for more information.
- If this is an internal request coming from and for Platform One then the CSO Support Hub is the best option.
If the request is approved then the project is created at the desired location within repo1
An email is then sent out to the POC and designated engineers with a link to the new project and some relevant documentation.
An initial issue is then created and assigned to the listed primary engineers from the onboarding request form to start hardening the container.

For users that are needing to pull in resources/binaries that are hosted in a private package repository that requires authentication to access.

A user will need to open a new issue in dccscr or in the corresponding project.
The CSO team will gather the required information. (This is asked in the issue template)
We will then create these credentials and add them to the desired group or project.
Last step is to notify the requestor and verify functionality.
(It is important not to put any sensitive information in the repo1 issue. This will be handled via DOD Safe.)

Robot accounts are requested frequently for uses in automating image pulls from registry1 so users do not have to use their own credentials.

This can be requested at dccscr.
There is a set of questions asked of the requestor/POC for information used to create the Robot Account
Once the Robot Account has been created, the automation script will use the email [ironbank@dsop.io] to send the requestor the robot account credentials.

This issue is to be opened once an initial feature branch has been pushed to repo1 for approval of the project.

The feature branch pipeline will fail at the "lint" stage until the project has been approved by the Onboarding team.
Once the pipeline has failed a notification is auto generated for the Onboarding team in VAT. (This will be resolved faster if the Vendor/Contributor opens an issue in dccscr or the corresponding project.)
The Onboarding team then looks into the projects posture:
- Folder structure.
- No source code/binaries in the project.
- LICENSE is present and valid.
- README.md is present and valid.
- The hardening_manifest is formatted correctly and contains the correct information.
- The Dockerfile is formatted correctly and contains the correct information.
- (Biggest "Gotchyas" on this stage are the naming convention in the hardening_manifest and missing files(README.md and LICENSE))
- Once the project adheres to Iron Bank's guidelines and policies the request is approved and the pipeline is reran.

The VAT read only API is for pulling vulnerability information on containers within Iron Bank.

You will need to request this via the dccscr project in repo1 and use the corresponding issue template.
Some information is required for this.
Once all information is received we will send credentials via DOD Safe.

Users do not automatically have write access to VAT to justify findings. A request is needed before that is granted.

Once a project has made it through a successful feature branch pipeline. (This includes warnings at stages throughout). Findings will be uploaded to the Iron Bank VAT tool and can be remediated or justified.
An issue can be opened in dccscr or in the corresponding project.
- It is assumed that the requestor has development level access to the project in question but if not then approval is needed from a current maintainer/developer.
The Onboarding team will grant write permissions to VAT for that user.
The Contributor/Vendor will need to request access again from within VAT for each individual project.
A request is auto generated for the Onboarding team and is approved (If the user has developer level access to the corresponding project in repo1).