Bug 1689149

Summary: Aggregated Logging installation does not add secret to serviceaccount
Product: OpenShift Container Platform Reporter: Simon Reber <sreber>
Component: LoggingAssignee: ewolinet
Status: CLOSED ERRATA QA Contact: Anping Li <anli>
Severity: medium Docs Contact:
Priority: high    
Version: 3.9.0CC: aos-bugs, ewolinet, rmeggins
Target Milestone: ---   
Target Release: 3.9.z   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: When using secret whitelisting the openshift-logging roles don't add the secret names to the created service accounts. Consequence: the service accounts don't have permissions to access the secrets. Fix: Secrets to be used by service accounts are added during SA creation. Result: The SA is able to use the secret even when whitelisting is used.
Story Points: ---
Clone Of:
: 1690603 1690605 (view as bug list) Environment:
Last Closed: 2019-04-09 14:20:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1690603, 1690605    

Description Simon Reber 2019-03-15 09:53:20 UTC
Description of problem:

When installing OpenShift Container Platform - Aggregated Logging, running playbooks/openshift-logging/config.yml will trigger role `openshift_logging`.

In there, `serviceaccounts` are being created. Those are missing required secrets being assigned which is causing issues when secret whitelisting is being used for serviceaccounts (as they need to be added manually after the installation).

 - Elasticsearch

https://github.com/openshift/openshift-ansible/blob/release-3.9/roles/openshift_logging_elasticsearch/tasks/main.yaml#L74

 - Curator

https://github.com/openshift/openshift-ansible/blob/release-3.9/roles/openshift_logging_curator/tasks/main.yaml#L42

 - Fluentd

https://github.com/openshift/openshift-ansible/blob/release-3.9/roles/openshift_logging_fluentd/tasks/main.yaml#L68

 - Kibana

https://github.com/openshift/openshift-ansible/blob/release-3.9/roles/openshift_logging_kibana/tasks/main.yaml#L45

Since `oc_serviceaccount` does support adding secrets to serviceaccount (https://github.com/openshift/openshift-ansible/blob/release-3.9/roles/lib_openshift/library/oc_serviceaccount.py#L95) this functionality should be used to better control the secret assignment.

When checking the details after successful installation, the following secrets should be added using the above function.

> aggregated-logging-fluentd:
> - logging-fluentd
> kibana:
> - logging-kibana
> - logging-kibana-proxy
> aggregated-logging-curator:
> - logging-curator
> aggregated-logging-elasticsearch:
> - prometheus-tls
> - logging-elasticsearch

Version-Release number of selected component (if applicable):

> oc v3.9.68
> kubernetes v1.9.1+a0ce1bc657
> features: Basic-Auth GSSAPI Kerberos SPNEGO

How reproducible:

 - Always

Steps to Reproduce:
1. Install OpenShift Container Platform - Aggregated Logging, following https://docs.openshift.com/container-platform/3.9/install_config/aggregate_logging.html#deploying-the-efk-stack
2. Check if and what secerts are being added to the respective service accounts the pods are running with
3.

Actual results:

None of the required secret is added to the respective service account

Expected results:

Required secrets added to the respective serviceaccount as per list below (may need to be extended in case I missed any)

> aggregated-logging-fluentd:
> - logging-fluentd
> kibana:
> - logging-kibana
> - logging-kibana-proxy
> aggregated-logging-curator:
> - logging-curator
> aggregated-logging-elasticsearch:
> - prometheus-tls
> - logging-elasticsearch

Additional info:

Issue is also present in OpenShift Container Platform 3.10 and 3.11

Comment 4 Anping Li 2019-03-25 10:56:24 UTC
The secret are append to whitelisting in openshift-ansible:v3.9.74

Comment 6 errata-xmlrpc 2019-04-09 14:20:18 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:0619