Bug 1753156 - [MSTR-829] kube-apiserver pod cannot access external https address after proxy CA is set
Summary: [MSTR-829] kube-apiserver pod cannot access external https address after prox...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.2.0
Assignee: Stefan Schimanski
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-18 09:37 UTC by Xingxing Xia
Modified: 2019-10-16 06:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:41:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-kube-apiserver-operator pull 567 0 'None' closed Bug 1753156: Fix the trusted-ca bundle filename 2020-10-26 17:15:24 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:41:45 UTC

Comment 1 Xingxing Xia 2019-09-18 10:59:54 UTC
More result: testing the webhook case OCP-25161, it got:
cat > smooth-app.pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: smooth-app
spec:
  containers:
  - image: openshift/hello-openshift
    name: smooth-app
EOF

# This test got equivalent error result with above step 3 IMO.
oc create -f smooth-app.pod.yaml
Error from server (InternalError): error when creating "smooth-app.pod.yaml": Internal error occurred: failed calling webhook "xxia.admission.webhook": Post https://grumpy-default.apps.<masked>.qe.devcluster.openshift.com/validate?timeout=30s: x509: certificate signed by unknown authority

Commented PR BTW https://github.com/openshift/cluster-kube-apiserver-operator/pull/567#discussion_r325609997

Comment 3 Xingxing Xia 2019-09-19 07:56:16 UTC
The issue of comment 0 is verified in 4.2.0-0.nightly-2019-09-19-014231. But the issue of comment 1 still exists. Still investigating and will report separate bug later if the issue is considered a bug.

Comment 4 Daneyon Hansen 2019-09-23 16:42:35 UTC
Xingxing regarding comment #1, platform components request CA injection by 1) creating a configmap with label 'config.openshift.io/inject-trusted-cabundle=true' in the same namespace as the pod 2) mounting the configmap as the local trust store like so:

---
kind: Pod/Deployment/DaemonSet/etc..
<SNIP>
          volumeMounts:
            - name: trusted-ca
              mountPath: /etc/pki/ca-trust/extracted/pem/
<SNIP>
      volumes:
        - name: trusted-ca
          configMap:
            name: trusted-ca
            optional: true
            items:
            - key: ca-bundle.crt
              path: tls-ca-bundle.pem

Comment 5 Xingxing Xia 2019-09-24 02:42:13 UTC
(In reply to Daneyon Hansen from comment #4)
> Xingxing regarding comment #1, platform components request CA injection by
Thanks Daneyon, yeah, for cluster components, that is correct. But comment 1 is not regarding cluster components, it is a step of the test case OCP-25161.

Comment 6 errata-xmlrpc 2019-10-16 06:41:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2922


Note You need to log in before you can comment on or make changes to this bug.