remove hashicorp kms libraries from trusted resources

[Yongxuanzhang]

Changes

This commit removes hashicorp kms libraries to unblock other tekton developers, details in #6015. In tep-91 we pulled in hashicorp kms libraries, and by running hack/update-codegen.sh it will copy the code into third_party directory. This will cause failures to ci jobs since it uses internal pkg. This is a short term solution to unblock other pipeline developers. Long term goal is to exclude checking third_party in our ci.

/kind misc

Signed-off-by: Yongxuan Zhang [email protected]

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

remove hashicorp kms libraries from trusted resources, so trusted resources don't support hashivault kms

[tekton-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign lbernick after the PR has been reviewed.
You can assign the PR to them by writing /assign @lbernick in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Yongxuanzhang]

/test all

[lbernick]

thanks @Yongxuanzhang -- what's the expected impact of not supporting hashivault for trusted resources? Will this be added back in later?

[Yongxuanzhang]

thanks @Yongxuanzhang -- what's the expected impact of not supporting hashivault for trusted resources? Will this be added back in later?

Currently we support loading kms from azure, aws, gcp and hashivault, so this means we will remove hashivault from our supported kms libraries.
Since trusted resources is alpha feature and we may don't have users yet. I think the impact is minimized.
We can add it back when we figure out how to exclude running third_party unit tests, on licenses or it is a feature request from users.

[lbernick]

Currently we support loading kms from azure, aws, gcp and hashivault, so this means we will remove hashivault from our supported kms libraries. Since trusted resources is alpha feature and we may don't have users yet. I think the impact is minimized. We can add it back when we figure out how to exclude running third_party unit tests, on licenses or it is a feature request from users.

I'd like to unblock #6342 and this sounds reasonable to me, but I don't love the idea of removing a feature we plan to add back later. Can anyone from the security wg comment on whether this is the right way to go or whether it makes sense to address the issue with hashicorp libraries directly?

Also, it seems like the problem described in #6015 isn't that we run unit tests on code in third_party; it seems like the problem is that there are security vulnerabilities detected by CodeQL. Maybe this is a signal that we should not import this library until the vulnerabilities are resolved?

[Yongxuanzhang]

Currently we support loading kms from azure, aws, gcp and hashivault, so this means we will remove hashivault from our supported kms libraries. Since trusted resources is alpha feature and we may don't have users yet. I think the impact is minimized. We can add it back when we figure out how to exclude running third_party unit tests, on licenses or it is a feature request from users.

I'd like to unblock #6342 and this sounds reasonable to me, but I don't love the idea of removing a feature we plan to add back later. Can anyone from the security wg comment on whether this is the right way to go or whether it makes sense to address the issue with hashicorp libraries directly?

Also, it seems like the problem described in #6015 isn't that we run unit tests on code in third_party; it seems like the problem is that there are security vulnerabilities detected by CodeQL. Maybe this is a signal that we should not import this library until the vulnerabilities are resolved?

Yes that's a good suggestion. I will bring this up tobthe wg and see if there are other ways.

Vulnerabilities from CodeQL are just part of the problem iirc. Their libraries will fail the unit tests since we run go test./...

[lbernick]

Yes that's a good suggestion. I will bring this up tobthe wg and see if there are other ways.

Thanks!

Vulnerabilities from CodeQL are just part of the problem iirc. Their libraries will fail the unit tests since we run go test./...

I'm not seeing the unit test failures you're describing, can you point me to an example? Unit tests pass in #6342

[Yongxuanzhang]

Yes that's a good suggestion. I will bring this up tobthe wg and see if there are other ways.

Thanks!

Vulnerabilities from CodeQL are just part of the problem iirc. Their libraries will fail the unit tests since we run go test./...

I'm not seeing the unit test failures you're describing, can you point me to an example? Unit tests pass in #6342

Ah, maybe it is fixed? Let me take a look

[Yongxuanzhang]

Yes that's a good suggestion. I will bring this up tobthe wg and see if there are other ways.

Thanks!

Vulnerabilities from CodeQL are just part of the problem iirc. Their libraries will fail the unit tests since we run go test./...

I'm not seeing the unit test failures you're describing, can you point me to an example? Unit tests pass in #6342

Oh indeed! This these libraries are not blocking unit tests/build tests anymore, maybe they have fixed it upstream.
For the CodeQL warning, maybe we could turn them off? Is it a block for ci?

[Yongxuanzhang]

no need to remove it since we have removed third_party in #6416