Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,150
    • Issues 44,150
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,427
    • Merge requests 1,427
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #294440
Closed
Open
Created Dec 17, 2020 by davidtacheny@dtachenyContributor

Vault JSON Web Token (JWT) ref_type "environment" for GitLab Environments.

Release notes

We've shipped Vault JWT token support in GitLab to simplify integrations with HashiCorp Vault. From the launch users could restrict access on various data contained in the JWT. One such data that our users were looking after was to restrict access to credentials using the environment name the current job targets. Until now, this was not possible.

The current release of GitLab extends the existing Vault JWT token to support environment based restrictions too. As the environment name could be supplied by the user running the pipeline, we recommend to use the new environment based restrictions with the already existing ref_type values for maximum security.

https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html

Problem to solve

Business workflows that use the GitLab Environments and protected Environments feature for continuous deployments would be able to pull Vault secrets based on the deployment environment and branch instead of needing to create new branches for environments.

Intended users

Any GitLab customer using the Continuous Deployment feature Environments and Vault.

User experience goal

The goal is to simplify Vault integration with GitLab Environments workflow for deployments. JWT Vault intake could build stronger bound claims to further protect secrets.

Proposal

Add two extra claims to the JWT:

  • environment to contain the name of the deployed environment
  • environment_protected to indicate whether the environment is protected (GitLab Premium feature)

Further details

Business workflows that use the GitLab Environments and protected Environments feature for continuous deployments would be able to pull Vault secrets based on the deployment environment and branch instead of needing to create new branches for environments. To simplify Vault integration with GitLab Environments workflow for deployments. JWT Vault intake could build stronger bound claims to further protect secrets.

Permissions and Security

N/A

Documentation

Availability & Testing

What does success look like, and how can we measure that?

Success is the JWT has an additional ref_type for "environments" that is filled by the GitLab Environments.

What is the type of buyer?

N/A

Is this a cross-stage feature?

N/A

Links / references

Edited Feb 17, 2021 by Tiger Watson
Assignee
Assign to
Time tracking