Bug 1884812

Summary:	When ES starts up, it displays warnings regarding cert permissions
Product:	OpenShift Container Platform	Reporter:	ewolinet
Component:	Logging	Assignee:	ewolinet
Status:	CLOSED ERRATA	QA Contact:	Giriyamma <gkarager>
Severity:	low	Docs Contact:	Rolfe Dlugy-Hegwer <rdlugyhe>
Priority:	low
Version:	4.6	CC:	aos-bugs, periklis, rdlugyhe, scuppett
Target Milestone:	---	Keywords:	Reopened
Target Release:	4.7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	logging-exploration
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	[discrete] [id="ocp-4-7-reduced-cert-warnings"] // https://bugzilla.redhat.com/show_bug.cgi?id=1884812 ==== Reduce Elasticsearch pod certificate permission warnings Previously, when the Elasticsearch pod started up, it generated certificate permission warnings, which misled some users to troubleshoot their clusters. The current release fixes these permissions issues to reduce these types of notifications.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-02-24 11:21: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:

Description ewolinet 2020-10-02 20:38:42 UTC

Description of problem:
When starting up we see the following in the ES logs:

Directory /etc/elasticsearch/secret has insecure file permissions (should be 0700)
File /etc/elasticsearch/secret/admin.p12 has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/admin.jks has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/elasticsearch.p12 has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/searchguard.key has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/logging-es.p12 has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/key has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/truststore has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/searchguard.truststore has insecure file permissions (should be 0600)
File /etc/elasticsearch/index_settings has insecure file permissions (should be 0600)

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


How reproducible:
Always


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 5 Giriyamma 2020-10-09 12:40:56 UTC

Verified this bug on Cluster version is 4.6.0-0.nightly-2020-10-07-022140, no more seeing 'has insecure file permissions' logs in ES pods.

Comment 6 Giriyamma 2020-10-13 12:16:00 UTC

Saw the issue again in cluster 4.6.0-0.nightly-2020-10-12-223649

oc get csv
NAME                                           DISPLAY                  VERSION                 REPLACES   PHASE
clusterlogging.4.6.0-202010120952.p0           Cluster Logging          4.6.0-202010120952.p0              Succeeded
elasticsearch-operator.4.6.0-202010130127.p0   Elasticsearch Operator   4.6.0-202010130127.p0              Succeeded

Directory /etc/elasticsearch has insecure file permissions (should be 0700)
Directory /etc/elasticsearch/scripts has insecure file permissions (should be 0700)
Directory /etc/elasticsearch/secret has insecure file permissions (should be 0700)
File /etc/elasticsearch/secret/admin.jks has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/searchguard.key has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/key has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/truststore has insecure file permissions (should be 0600)
File /etc/elasticsearch/secret/searchguard.truststore has insecure file permissions (should be 0600)
File /etc/elasticsearch/index_settings has insecure file permissions (should be 0600)

Comment 7 Stephen Cuppett 2020-10-13 12:50:56 UTC

Setting target release to the active development branch (4.7.0). For any fixes, where required and requested, cloned BZs will be created for those release maintenance streams where appropriate once they are identified.

Comment 9 Stephen Cuppett 2020-10-13 15:16:03 UTC

Setting target release to the active development branch (4.7.0). For any fixes, where required and requested, cloned BZs will be created for those release maintenance streams where appropriate once they are identified.

Setting a tentative severity based on description as provided.

Comment 11 Jeff Cantrill 2020-10-23 15:20:29 UTC

Setting UpcomingSprint as unable to resolve before EOD

Comment 13 Giriyamma 2020-11-10 13:32:25 UTC

Still seeing below 2 lines in ES pod logs:

Directory /etc/elasticsearch has insecure file permissions (should be 0700)
Directory /etc/elasticsearch/scripts has insecure file permissions (should be 0700)

Comment 14 ewolinet 2020-11-10 14:54:18 UTC

(In reply to Giriyamma from comment #13)
> Still seeing below 2 lines in ES pod logs:
> 
> Directory /etc/elasticsearch has insecure file permissions (should be 0700)
> Directory /etc/elasticsearch/scripts has insecure file permissions (should
> be 0700)

Those are expected to be there. Due to how we configure ES running we are unable to clear those for now.

Comment 15 Giriyamma 2020-11-11 03:46:14 UTC

as per Comment 13 , the issue is fixed.

Comment 21 errata-xmlrpc 2021-02-24 11:21: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 (Errata Advisory for Openshift Logging 5.0.0), 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-2021:0652