- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1k
feat(repo-server): Declare custom trust certs for repo-server and plugins #1876
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat(repo-server): Declare custom trust certs for repo-server and plugins #1876
Conversation
| Compared to the proposal in #1876, it turned out 1 init container is enough. Also, this implements  | 
| /ok-to-test | 
9e0a19d    to
    4653fab      
    Compare
  
    | The "Code scans / Run golangci-lint and gosec (pull_request)" failure to be adressed by #1880 | 
| The test failures are related to the fact the code depends on a tech-preview features. Any advise on how to handle such functionality? | 
93a8f75    to
    2e5afb6      
    Compare
  
    | // ClusterTrustBundles is a list of projected ClusterTrustBundle volume definitions from where to take the trust certs. | ||
| ClusterTrustBundles []corev1.ClusterTrustBundleProjection `json:"clusterTrustBundles,omitempty"` | ||
| // Secrets is a list of projected Secret volume definitions from where to take the trust certs. | ||
| Secrets []corev1.SecretProjection `json:"secrets,omitempty"` | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can it be SecretRefs instead of SecretProjection ? What is the advantage we get by using SecretProjection instead of referring a Secret directly which can be read directly by the operator code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, projections are the only way (I know off), to create a single volume from multiple sources. So this can combine all three kinds of sources in any quantity, and the entries will be merged in a single directory making the init container completely agnostic of files' origin.
If customers are to create the Secret or CM manually, using only one resource might not be that much to ask. But ability to merge them permits seemless integration with signed ClusterTrustBundles that are likely to have more than one resource.
de515ac    to
    448e641      
    Compare
  
    c0a9ad2    to
    448e641      
    Compare
  
    … or plugins Signed-off-by: Oliver Gondža <[email protected]>
…plugins from Secrets and CMs Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
… CTB support Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
Signed-off-by: Oliver Gondža <[email protected]>
dfe7ca7    to
    198d41d      
    Compare
  
    …rustBundles to repo-server automatically Signed-off-by: Oliver Gondža <[email protected]>
198d41d    to
    9c3639c      
    Compare
  
    
What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
Permit users to trust CAs on a repo-server system level
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #1830
How to test changes / Special notes to the reviewer:
Can be tested against: