SHIP-0042: Trusted certificates #281
Conversation
Proposal to add a Shipwright feature to use trusted certificates in Build steps. Signed-off-by: Sayan Biswas <[email protected]>
openshift-ci
bot
added
the
do-not-merge/work-in-progress
pull-request-size
bot
added
the
size/L
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
adambkaplan
left a comment
adambkaplan
left a comment
There was a problem hiding this comment.
Initial comments since this proposal is in the draft state. I'd like to see the scope of this proposal more clearly defined before accepting it in the "provisional" state.
| @@ -0,0 +1,121 @@ | |||
| # Trusted Certificates | |||
There was a problem hiding this comment.
Please restore the YAML metadata at the top of the template. We use this to track the lifecycle of the proposal.
| - name: custom-cert-1 | ||
| secretName: ca-cert-1 | ||
| mountPath: /etc/ssl/cert # This is optional and will default to configuration from system parameter (see below) | ||
| - name: custom-cert-2 | ||
| secretName: ca-cert-2 |
There was a problem hiding this comment.
We will need to handle multiple types of objects for certificate data:
ConfigMap- TLS certificate authorities are often distributed as ConfigMaps, as this information is intended to be public. This is perhaps the most common use case for this feature when it comes to accessing content in private Git repositories and image registries. Trust Manager defaults to distributing CAs bundles with a ConfigMap. I would prioritizeConfigMapsupport for this feature overSecrets.- Kubernetes has a new feature, ClusterTrustBundles, which graduated to beta in v1.33 but is disabled by default. These trust bundles can be mounted into pods using a new projected volume type. We should consider adding support for this once v1.33 becomes our minimum supported version.
| The default path where the certificates will be mounted is defined in the system parameter API of the build strategy. | ||
| https://shipwright.io/docs/build/buildstrategies/#system-parameters | ||
|
|
||
| params.shp-certificate-directory |
There was a problem hiding this comment.
What value is the default? Let's be explicit here.
| # ... | ||
| spec: | ||
| # ... | ||
| certificates: |
There was a problem hiding this comment.
I like that we are supporting multiple certificates - this enables more fine grained distribution of trust.
I am concerned that the naming "certificates" is too broad. Are we concerned with certificate authorities for TLS verficiation? X.509 certificates for workload identity? Mutual TLS certificates between services? These are all very different things that utilize similar underlying fundamental technologies.
2 participants
Proposal to add a Shipwright feature to use trusted certificates in Build steps.
Changes
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes