Closed ricardoapl closed 3 months ago
This issue is currently awaiting triage.
If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
If https://github.com/kubernetes/kube-state-metrics/pull/2398 is getting merged, will this workflow work with only read permissions?
If #2398 is getting merged, will this workflow work with only read permissions?
That's a good point, the workflow will not work with read only permissions then.
I suggest we keep default top-level permissions to read-only, but add contents: write
permissions at job-level to #2398.
Although perhaps unlikely, there's a chance that a new job is added to this workflow, and its permissions could be left undefined because of human error.
What do you think?
Sounds good to me, let's mark this read-only for now.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mrueg, ricardoapl
The full list of commands accepted by this bot can be found here.
The pull request process is described here
What this PR does / why we need it:
The
GITHUB_TOKEN
is an automatically generated secret to make authenticated calls to the GitHub API. GitHub recommends setting minimum token permissions for theGITHUB_TOKEN
, otherwise attackers may use a compromised token with write access to, for example, push malicious code into the project.Found in CLOMonitor Checks and OpenSSF Scorecard Report.
How does this change affect the cardinality of KSM:
Does not change cardinality
Which issue(s) this PR fixes:
Part of #2274