CNTRLPLANE-3424: Document tls injection#2044
Conversation
…or TLS injection into ConfigMaps
openshift-ci-robot
added
the
jira/valid-reference
|
@vincentdephily: This pull request references CNTRLPLANE-3424 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 "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[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. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
vincentdephily
force-pushed
the
vdp-tls-inject
branch
from
a7f1ac5 to
bf316c9
Compare
|
@vincentdephily: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| ### How the TLS stack uses this config | ||
|
|
||
| Although this config gives a lot of control, operators often ignore some of te nuance. In particular, operators using the Go TLS stack (all upstream OpenShift ones) ignore the ciphersuites preference order, and with TLS 1.3 ignore the ciphersuite list completely. |
|
|
||
| ### Workflow | ||
|
|
||
| The TLS injection is implemented as a ConfigMap modifier in the resource builder (`lib/resourcebuilder/core.go`). When the resource builder processes a ConfigMap manifest from the release image, it calls `modifyConfigMap` before applying the ConfigMap to the cluster. |
There was a problem hiding this comment.
Private methods can drift a lot or get removed in the future. Making the description less useful. It's more practical to mention the flow in an abstract way rather than referring to private symbols.
|
|
||
| It then looks for `data` configmaps of the right kind (currently `GenericOperatorConfig` and `GenericControllerConfig`) and corresponding API version. Those `data` nodes are updated with the observed `servingInfo.minTLSVersion` and `servingInfo.cipherSuites`. | ||
|
|
||
| The ressourcebuilder will then apply the configmap, if it actually differs from the original one. |
There was a problem hiding this comment.
s/ressourcebuilder/resourcebuilder/
| ## Operator Implementations | ||
|
|
||
| Operators (or more generally controllers) only need to | ||
| * Be based on `library-go`: |
There was a problem hiding this comment.
need -> strongly recommended
| - Only supports `GenericOperatorConfig` and `GenericControllerConfg` formats | ||
| - Only injects `servingInfo.minTLSVersion` and `servingInfo.cipherSuites` | ||
| - Requires the operator to watch and reload its ConfigMap when it changes | ||
| - Only available for ConfigMaps in the release image (not for user-created ConfigMaps) No newline at end of file |
There was a problem hiding this comment.
nit: release -> payload. I think mentioning "payload" keyword makes it more precise.
|
|
||
| ### Cluster configuration | ||
|
|
||
| See [TLS security profile](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/security_and_compliance/tls-security-profiles) to set the cluster-wide config. |
There was a problem hiding this comment.
s/4.21/latest (latest will get redirected to the latest version, 4.22 atm)
|
|
||
| TLS injection occurs when applying or reconciling the configmap | ||
|
|
||
| 1. During installation, apply the ConfigMap from the release image |
3 participants
This builds on top of #2020