Revise the following guidance
|
### Source code |
|
|
|
Access to a source code system was identified during discussions |
|
of the AAW environment. |
|
|
|
A source code system available to both unclassified and Protected B |
|
workloads introduces some complications from a security posture, |
|
and in particular how to prevent data exfiltration from the environment. |
|
|
|
Therefore, there are three proposals on how to implement a source |
|
code system in AAW: |
|
|
|
> **Recommendation NET-ES-03**: For source code, |
|
> |
|
> 1. Continue to use external source code systems for unclassified workloads. |
|
> This is permitted via TBS policy: |
|
> |
|
> > 6.1: Departments are to enable open access to the Internet for GC |
|
> > electronic networks and devices, including GC and external Web 2.0 |
|
> > tools and services, to authorized individuals, as per Section 6.1.3 |
|
> > of the Policy on Acceptable Network and Device Use (PANDU). |
|
> > |
|
> > — https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=32588#cha5 |
|
> |
|
> and launch an internal-only GitLab instance accessible |
|
> only to Protected B workloads. |
|
> |
|
> 2. Launch a GitLab instance in the AAW environment which is |
|
> available to all workloads. Workloads running at the |
|
> Protected B level are granted only HEAD / GET requests |
|
> to the GitLab instance (to prevent data exfiltration). |
|
> POST requests to specificly authorized endpoints, |
|
> such as for authorization, will be allowed. |
|
> |
|
> 3. Two seperate GitLab instances be launched in the AAW |
|
> environment, 1 for unclassified and 1 for Protected B. |
|
> This is the least recommended solution due to the |
|
> maintenance overhead. |
|
> |
|
> **DAaaS should identify the best solution based on the |
|
> needs of its users, and therefore this proposal |
|
> does not specify a specific solution.** |
Add the new reocmmendations for an architecture around per-namespace Gitea, highlighting the simplicity for multi-tenancy and authentication, and enablement of MLOps.
Consider studying a mechanism for providing a read-only mirror of the unclassified gitea for use in protected-b notebooks, perhaps using this:
https://docs.gitea.io/en-us/repo-mirror/#pulling-from-a-remote-repository
Revise the following guidance
aaw-security-proposal/05-network.md
Lines 88 to 129 in 429d3d7
Add the new reocmmendations for an architecture around per-namespace Gitea, highlighting the simplicity for multi-tenancy and authentication, and enablement of MLOps.
Consider studying a mechanism for providing a read-only mirror of the unclassified gitea for use in protected-b notebooks, perhaps using this:
https://docs.gitea.io/en-us/repo-mirror/#pulling-from-a-remote-repository