THREESCALE-10236 Custom CA certificate support for operator deployment - #1181
Conversation
|
Skipping CI for Draft Pull Request. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1181 +/- ##
==========================================
+ Coverage 44.03% 44.65% +0.62%
==========================================
Files 204 208 +4
Lines 20960 21235 +275
==========================================
+ Hits 9230 9483 +253
- Misses 10933 10952 +19
- Partials 797 800 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
4c92127 to
1ef25a4
Compare
15d9757 to
7284dae
Compare
|
/retest |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
77d65d3 to
06f126f
Compare
tkan145
left a comment
There was a problem hiding this comment.
Do we really need all of those CR tests and mock just to test API call?
The most important thing is that ca_bundler_watcher is not tested anywhere.
0163710 to
18c6492
Compare
As discussed, added the ca_bundler_watcher reconciler test and removed the mocked tests to be replaced in functional test in the future to eliminate the mocks. |
18c6492 to
8f91974
Compare
b335c16 to
7caedce
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
7caedce to
dc80df8
Compare
…ents Introduce a new CABundleWatcher controller that watches the threescale-ca-bundle ConfigMap and atomically publishes its parsed x509.CertPool to a package-level variable. The CA changes are watched on all replicas of operator, not just leader to have warmed up cache in case of a switchover. Use the pool in all PortaClient* constructors in pkg/controller/helper so that outbound TLS connections to the 3scale Admin API automatically trust operator-configured CAs; insecureSkipVerify bypasses this when set. Co-Authored-By: IBM Bob <AskBob@ibm.com>
dc80df8 to
4690e33
Compare
|
/lgtm |
The 3scale operator connects to the 3scale Admin API (and, via the Tenant controller, the Master API) to reconcile capabilities CRs (Backend, Product, Application, ActiveDoc, etc.). These connections use HTTPS.
In environments where 3scale is deployed with internal or self-signed CA, the operator's HTTP client rejects the connection because the CA is not in the system trust store. The existing workarounds — the
insecure_skip_verifyannotation and patching the operator Subscription to mount a CA viaSSL_CERT_FILE(Red Hat Solution 7049968) — are either insecure or fragile (overwritten on upgrades).Customers need a way to provide a custom CA bundle so the operator can trust internal CAs without disabling verification.
Sources of 3scale connections (each with different credential configuration):
providerAccountRef: the CR references a Secret containingadminURLandtoken.threescale-provider-accountsecret: a well-known Secret name. Same schema as source 1 but discovered by convention.system-seed.masterCredentialsRefsecret (defaulting tosystem-seed) containing master API credentials.This PR adds ability to configure a custom CA bundle when connecting to any of the above endpoints. The bundle will be loaded from a well-known configmap from the operator namespace (
threescale-ca-bundle) and will be reloaded automatically if a change is detected.Testing:
The testing follows 3 scenarios when using a standard deployment of APIManager on creating a backend resource without secret -> the backend reconciler will fall back to endpoint for local APIManager.
Result:
insecure_skip_verifywould bypass the problem:Result:
Result:
Result:
Result:
Tested using live cluster with following configuration (with catalog image built from the PR branch):
Result:
Backend status before upgrade:
After upgrade with custom CA: