Namespace Configuration Options
These options are set by the Workshop team on behalf of each customer. Changes to any of them can be made by submitting a support request via email.
Option categories
General namespace settings
Name
The name of your namespace serves as the top-level path to your home on Workshop. For example, the Namespace name Cloud.gov can be found at https://workshop.cloud.gov/cloud-gov
Description
A short description of the overall namespace. This can help people find the right place if your agency is using multiple namespaces, or your namespace is public.
Visibility
The visibility of your namespace controls how public or private your Workshop namespace is.
publicthe namespace and public subgroups and projects within it can be viewed without logging into Workshop.internalthe namespace and internal subgroups and projects within it can be viewed by any logged-in Workshop user, even if that user is a member of a different namespace. Remember that Workshop users all must have.govemail addresses.privateusers must be explicitly granted access to all projects.
Subgroups and projects within a namespace can be made more private than the namespace, but cannot be more public than the namespace.
User management
Users
Workshop must provision user accounts for all users who will have access to your namespace. For each user you wish to add, send us each user's
- Government email address
- Full name
You must also let us know when a user should no longer be allowed access to Workshop, for instance when they transfer to a new role or leave your agency.
All Workshop users must log in via Cloud.gov UAA, which integrates with agency single-sign-on systems.
Owners
At least two of your users should be assigned as owners of the namespace. In addition to the default GitLab permissions of an owner, a Workshop namespace owner has the important duty of reviewing, approving, and merging changes to your namespace's config project
Egress configuration
Worker egress
Workshop CI runners implement egress traffic control to protect your code and data from exfiltration.
In order to properly configure your allowlist, create a support request with:
- the list of technologies that your projects expect to use
- a list of any other domain names you want your runners to be able to connect to
- (optional) a list of domain names to explicitly deny access to
Service egress
By default, services are not permitted to make any outbound network calls. Send us a support request if you wish for services to have egress access and we will work with you to ensure your use case works properly.
Unsafe egress
If you have a job that cannot be made to work with the egress proxy, there is an option to enable a subset of runners to operate with unfettered network access. Send us a support request to review options and tradeoffs.
Any jobs run in an unsafe egress runner will be able to make network calls to any address on the internet, whether you intended that or not.
If it the responsiblity of the customer to properly secure these jobs.
CI/CD runners
There are several options related to general use of the Workshop Runner Service:
Pool Size
Pool size controls the number of parallel jobs that can run at the same time. See the pricing page for current pool size options.
Worker SSH ability
By default, jobs cannot ssh into their services, but there are some use-cases that make that ability useful.
For instance, it's a prerequisite for being able to use the image-builder CI component for building container images within Workshop Runners.
Docker Hub credentials
If your jobs use private images hosted in Docker Hub, your runner needs to have customized Docker Hub credentials provided to it. Private images that you host within your Workshop project's container registry will always be available to your jobs.
Do not include the credentials in the support request where you request that we customize these for you. We will follow up to get them sent securely.