AppDat Gitlab User Guide #

AppDat operates a “self-hosted” version of Gitlab Ultimate on a FedRAMP compliant, NASA authorized cloud computing platform .

Gitlab serves as the configuration and security management “single source of truth” for all aspects of the AppDat Platform itself, as well as AppDat managed customer applications. Utilization of the AppDat Gitlab, and adherence to the AppDat DevSecOps operational models, are required for full coverage

Access #

Accessing the AppDat Gitlab is restricted to authenticated users only, authorization is set to “Base Level Entitlement” (BLE) for all NASA credentialed users. Anyone with a NASA login is able to access any projects or group wikis that are configured as “Internal”, projects that are configured as “Private” are only accessible to the project members explicitly added to the project or project’s group.

For more information on the visibility of projects within Gitlab see here

Developer CLI Usage Authentication #

In addition to accessing AppDat Gitlab via the web-browser, Developers will need to also interact with the AppDat Gitlab via the underlying Git Command Line Interface or with GIT GUI Client .

SSH #

Git is a distributed version control system, which means you can work locally, then share or “push” your changes to a server. In this case, the server is GitLab.

GitLab uses the SSH protocol to securely communicate with Git. When you use SSH keys to authenticate to the GitLab remote server, you don’t need to supply your username and password each time.

At a high-level, setting up SSH based user authentication involves the following steps:

Other configuration requirements may be required, see the full Gitlab SSH documentation here for more information

Personal Access Tokens #

Developers can use a personal access token to authenticate with the GitLab API. You can also use a personal access token with Git to authenticate over HTTPS. Personal Access Tokens are used in place of a password and are provisioned with specific “scopes” to limit their access level.

For more information on how to use Gitlab Personal Access Tokens see here

Projects #

In GitLab, you can create projects to host your codebase. You can also use projects to track issues, plan work, collaborate on code, and continuously build, test, and use built-in CI/CD to deploy your application or service.

Projects can also just be used for technical documentation (like this repository) or serve an “issues only” repositories

See here for a full listing of all the Gitlab project features

Create New Project #

AppDat Maintainers and Developers are allowed to create new projects within the Groups they are a member of. To create a project navigate to the desired group and follow the Gitlab “Create Project” Documentation .

Visibility Level #

When creating a new project you will have to specify a “Visibility Level”, within AppDat those levels map as follows:

Private: Only project members can view the project (Memberships are inherited from the group)
Internal: Only project members can contribute but ALL NASA users have read-only access

AppDat customer groups are restricted to “Internal” so the “Public” visibility level is not available without specific permissions*

For more information see the Gitlab documentation on the visibility of projects here

Groups #

In GitLab, you use groups to manage one or more related projects at the same time.

You can use groups to manage permissions for your projects. If someone has access to the group, they get access to all the projects in the group.

You can also view all the issues and merge requests for the projects in the group, and view analytics that show the group’s activity.

You can use groups to communicate with all the members of the group at once.

See here for the full documentation on Gitlab groups and subgroups

Permissions #

Permissions are handled at the project level, but Group level permissions to cascade down to their contained projects and subgroups. Permissions are tied specifically to specific roles .