Add support for GitLab to docs

content/en/about/security.md

@@ -10,24 +10,24 @@
 
 ## Proving Identity in Sigstore
 
-Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. 
+Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, GitLab, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. 
 
 ## Sigstore’s Trust Model
 
 Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio. 
 
 ### Sigstore’s Trust Root
 
 The Trust Root, which was established during a public [root key signing ceremony](https://www.youtube.com/watch?v=GEuFsc8Zm9U), is made up of a rotation of five keyholders from varying companies and academic institutions who contribute to Sigstore. It leverages the principles of [The Update Framework](https://theupdateframework.io/) (TUF), a set of defined attacks and threat models specific to software distribution systems. TUF provides a cleverly designed set of protocols to protect against these types of attacks, which the Trust Root follows.
 
 The Sigstore Trust Root is used to secure the keys used by the entire Sigstore project. It allows individuals and systems to automatically retrieve trusted keys and certificates used to verify artifacts produced by the Sigstore ecosystem. Using the Sigstore Trust Root, end users can verify:
 * Certificates issued by Fulcio
 * Entries in the Rekor transparency log
 This allows end users to verify (and trust) that the distributors of the software they use are who they say they are.
 
 For more details on the Trust Root or the key signing ceremony, see [A New Kind of Trust Root](https://blog.sigstore.dev/a-new-kind-of-trust-root-f11eeeed92ef). For an overview of TUF, see [The Update Framework and You](https://blog.sigstore.dev/the-update-framework-and-you-2f5cbaa964d5).
 
 ### Rekor Security Model
 The Rekor service provides a transparency log of software signatures. The log is append-only and once entries are added they cannot be modified; a valid log can be cryptographically verified by any third-party. As entries are appended into this log, Rekor periodically signs the full [Merkle tree](https://transparency.dev) along with a timestamp.
 
 An entry in Rekor provides a single-party attestation that a piece of data existed prior to a certain time. These timestamps and the contents of the log cannot be tampered with or removed later, providing long-term trust. This long-term trust also requires that the log is monitored.
@@ -36,9 +36,9 @@
 
 ### Fulcio Security Model
 
 One of the targets secured by the Sigstore Trust Root is the Fulcio root certificate, which is used to issue short-lived code signing certificates. 
 
 **Certificate Transparency Log**
 
 Fulcio assumes that a valid OIDC token from a trusted provider is sufficient “proof of ownership” of the associated identity. To mitigate against OIDC compromise, Fulcio appends certificates to an immutable, append-only cryptographically verifiable transparency log. This means:
 
@@ -49,11 +49,11 @@
 
 _Note: Fulcio itself does not monitor the certificate transparency log; users are responsible for monitoring the log for unauthorized certificates issued to their identities._
 
 **Short Lived Certificates**
 
 Fulcio also uses short-lived certificates as a solution to the key management problem. Traditional signing involves issuing long-lived certificates, but this method assumes that users won’t lose their private key or that the key won’t get stolen or otherwise compromised for long periods of time.
 
 Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid. 
 
 How can a user do that?
 
@@ -63,12 +63,12 @@
 
 Storing the signature in a transparency log also makes certificates easily discoverable so that maintainers don’t have to worry about public key distribution.
 
 **Ephemeral Keys**
 
 Sigstore clients like Cosign can also eliminate the key management problem by using ephemeral keys. These ephemeral keys only exist in memory; the private key never hits disk and is never known by Sigstore services.
 
 Cosign will:
 1. Generate an ephemeral public/private keypair in memory
 1. Bind the public key to a short-lived certificate requested from Fulcio
 1. Sign an artifact with the ephemeral private key while the certificate is still valid
 1. Store the signature and certificate in Rekor as proof the artifact was signed while the certificate was valid

content/en/certificate_authority/oidc-in-fulcio.md

@@ -30,6 +30,18 @@ GitHub supports OIDC tokens for its workflows initiated from GitHub Actions. Thi
 
 * GitHub Actions (`token.actions.githubusercontent.com`)
 
+GitLab supports OIDC tokens for its workflows initiated from GitLab CI/CD pipelines. This removes the need for persisting authentication credentials. OIDC tokens include information about the workflow and source repository.
+
+In GitLab, you can generate the necessary tokens by simply adding the following to your CI/CD job:
+
+```yaml
+id_tokens:
+    SIGSTORE_ID_TOKEN:
+      aud: sigstore
+```
+
+See the [GitLab documentation](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html) for full examples on signing through GitLab.
+
 ### SPIFFE
 
 SPIFFE-based OIDC providers use a SPIFFE ID as the URI subject alternative name of the certificate, scoped to a domain.
@@ -100,6 +112,33 @@ The token must include the following claims:
 
 All other required claims are extracted and included in custom OID fields, as documented in [OID Information](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md).
 
+### GitLab
+
+The token must include the following claims:
+
+```json
+{
+    "namespace_id": "72",
+    "namespace_path": "my-group",
+    "project_id": "20",
+    "project_path": "my-group/my-project",
+    "pipeline_id": "574",
+    "pipeline_source": "push",
+    "job_id": "302",
+    "ref": "main",
+    "ref_type": "branch",
+    "runner_id": 1,
+    "runner_environment": "gitlab-hosted",
+    "sha": "714a629c0b401fdce83e847fc9589983fc6f46bc",
+    "project_visibility": "public",
+    "ci_config_ref_uri": "gitlab.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main"
+}
+```
+
+`ci_config_ref_uri` is included as a SAN URI: `https://{ci_config_ref_uri}`
+
+All other required claims are extracted and included in custom OID fields, as documented in [OID Information](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#mapping-oidc-token-claims-to-fulcio-oids).
+
 ### SPIFFE
 
 The token must include the following claims:

content/en/system_config/installation.md

@@ -93,6 +93,15 @@ with:
   cosign-release: "v2.0.2" # optional
 ```
 
+## GitLab
+
+Cosign can be installed in your CI/CD pipeline by using a before script in your job:
+
+```yaml
+before_script:
+  - apk add --update cosign
+```
+
 ## Container Images
 
 Signed release images are available at [`gcr.io/projectsigstore/cosign`](http://gcr.io/projectsigstore/cosign).

content/en/verifying/verify.md

@@ -24,7 +24,7 @@ $ cosign verify <image URI> [email protected]
 
 ```
 
-The oidc-issuer for Google is https://accounts.google.com, Microsoft is https://login.microsoftonline.com, and GitHub is https://github.com/login/oauth.
+The oidc-issuer for Google is https://accounts.google.com, Microsoft is https://login.microsoftonline.com, GitHub is https://github.com/login/oauth, and GitLab is https://gitlab.com.
 
 The following example verifies the signature on file.txt from user [email protected] issued by [email protected]. It uses a provided bundle cosign.bundle that contains the certificate and signature.