Closed jackdelahunt closed 4 months ago
@jackdelahunt I know this is marked as Draft, but just wondering if it's actually needed? What's the overlap with #230?
@grdryn sorry I didn't update this much, this is for self signed certs with kserve. The other PR is just for git
@jackdelahunt: This pull request references RHOAIENG-4873 which is a valid jira issue.
Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.
@jackdelahunt: This pull request references RHOAIENG-4873 which is a valid jira issue.
Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.
- Where we say "self-signed cert", should we instead be saying something like "certificate authority"?
@grdryn
So the configmaps that get mounted to the pipeline runs are called git-self-signed-cert
and s3-self-signed-cert
. What should these be renamed to? Just git-cert
, git-CA-cert
or git-signed-cert
?
And then of course same thing goes for changing the naming of things with self signed in them
- I think we should prefer the term TLS cert rather than SSL cert.
While I agree TLS is the correct term there is potential confusion with underlying dependencies that still use the term SSL
for their public confgs & apis (See https://github.com/opendatahub-io/ai-edge/pull/241#discussion_r1562663813
). In documentation, we could enforce the use of SSL/TLS
where both apply or just tls
based features/configs that we own completely
Where we say "self-signed cert", should we instead be saying something like "certificate authority"? Just because a cert isn't trusted by default, doesn't mean that it's "self-signed", does it? It could be signed by a centralized CA owned by the users organisation, and I guess that's what they'd need to import here in that case, is it?
self-signed cert
is relative to whether it's issuer has been included in the trusted Certificate Authority bundle for the environment. Your example is correct and we are generalizing all of these "not trusted by default certificates" under the term self-signed cert
. In a perfect environment, this PR only adds support for working with S3 stores in non-production environments
While I agree TLS is the correct term there is potential confusion with underlying dependencies that still use the term SSL for their public confgs & apis (See https://github.com/opendatahub-io/ai-edge/pull/241#discussion_r1562663813 ). In documentation, we could enforce the use of SSL/TLS where both apply or just tls based features/configs that we own completely
I definitely haven't thought about this as much as you have (and don't necessarily fully understand all of the implications). My suggestion was mainly based on having a quick scan at other projects documentation, and how some appear to prefer "TLS certificate" rather than "SSL certificate" or SSL/TLS certificate". I don't have a strong enough opinion, so fine with it being ssl.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: grdryn, LaVLaS
The full list of commands accepted by this bot can be found here.
The pull request process is described here
I definitely haven't thought about this as much as you have (and don't necessarily fully understand all of the implications). My suggestion was mainly based on having a quick scan at other projects documentation, and how some appear to prefer "TLS certificate" rather than "SSL certificate" or SSL/TLS certificate". I don't have a strong enough opinion, so fine with it being ssl.
You are correct on the use of TLS over SSL. I have no object on using the TLS
or at minimum SSL/TLS
in all documentation. The use in the pipeline was just parity with its use in the git-clone task and kserve/storage library
/override ci/prow/test-ai-edge /lgtm
Adding override due to openshift-ci downtime and offline tests were successful for each use case with/without certs and existing functionality was preserved
@LaVLaS: Overrode contexts on behalf of LaVLaS: ci/prow/test-ai-edge
Description
Add support for using self signed certs with kserve to download models from an object store
How Has This Been Tested?
Use the e2e test provided in the repo
Setup e2e tests as normal
Set the new env variable
S3_SELF_SIGNED_CERT
as the path to the certAnd then run
Merge criteria: