Frontend: Encourage users to switch to OIDC when variables is prefixed with AWS_*
Summary
GitLab.com support OIDC with all the major cloud providers, including AWS and GCP.
Proposal
- Remove existing AWS banner:
- Move this
<gl-collapse>
/<gl-alert>
to the top of the modal
- Move this
- Display new banner when a user is creating a variable for
AMAZON
:- Change the props/contents of the alert:
variant="warning"
- title:
Use OIDC to securely connect to cloud services
- message:
GitLab CI/CD supports OpenID Connect (OIDC) to give your build and deployment jobs access to cloud credentials and services. [How do I configure OIDC for my cloud provider?](https://docs.gitlab.com/ee/ci/cloud_services/#oidc-authorization-with-your-cloud-provider)
- Keep the same
isTipVisible
anddismissTip
methods to conditionally show/hide the alert.- This means that the alert is initially shown if the variable name matches any of the
AWS_TOKEN_CONSTANTS
, then when the alert is dismissed using thex
in the corner, it will be hidden for the next 90 days (according to a boolean stored in a cookie).
- This means that the alert is initially shown if the variable name matches any of the
- Keep the same
data-testid="aws-guidance-tip"
for the alert so that the finder in the spec still works.
- Change the props/contents of the alert:
Additional details
Some relevant technical details, if applicable, such as:
- Does this need a feature flag?
- Does there need to be an associated instrumentation issue created related to this work?
- Is there an example response showing the data structure that should be returned (new endpoints only)?
- What permissions should be used?
- Is this EE or CE?
-
EE -
CE
-
- Additional comments:
Implementation Table
Group | Issue Link |
---|---|
frontend |
|
Links/References
Existing notes
Using CI/CD variables for cloud provider secrets should be discouraged as an insecure practice.GitLab.com support OIDC with all the major cloud providers, including AWS and GCP.
When a user attempts to add a secret that is a known cloud provider access key, the application should encourage them not to, and use OIDC for temporary credentials instead.
For example, if a user enters a new key such as AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, etc, we should discourage this approach and suggest they used the GitLab OIDC provider instead.
This approach would encourage better secret hygiene by both GitLab.com users and GitLab team members, and having the UI prompt users may help educate them to the benefits of this approach.