Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2237993

Summary:	[16.2] Applying OpenStackDeploy results in ssh permission errors when pulling from git repository
Product:	Red Hat OpenStack	Reporter:	Martin Schuppert <mschuppe>
Component:	osp-director-operator-container	Assignee:	Ollie Walsh <owalsh>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	16.2 (Train)	CC:	jsalibi, lmadsen, mschuppe, owalsh
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:	2236085	Environment:
Last Closed:	2024-10-23 13:56:27 UTC	Type:	---
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:	2236085
Bug Blocks:

Description Martin Schuppert 2023-09-08 09:42:21 UTC

+++ This bug was initially created as a clone of Bug #2236085 +++

Description of problem:
Execution / Re-execution / updates of deployments via applying an OpenStackDeploy results in permission error on config file in ~/.ssh directory for cloud-admin user:
```---
Cloning into '/home/cloud-admin/work/n5cbh54ch697h57bh56h664h648hbdh696h5ddh94h8fh67h59fh685h594hdbh65h57bh5f7h68dh559hb6hddh5bh588h75h695h5d7h5f4hch56q/playbooks'...
Bad owner or permissions on /home/cloud-admin/.ssh/config

fatal: Could not read from remote repository.
---```

viewing files shows that write permissions were added to the contents of the ~/.ssh directory for user cloud-admin:

```---
-rw-rw-r--.  1 cloud-admin cloud-admin   56 Jul 16 23:33 config
---```

Version-Release number of selected component (if applicable):
director operator bundle 1.13.0-17

How reproducible:
Not certain but likely every post run after initial OpenStackDeploy, however most noted after a failed OpenStackDeploy and fresh OpenStackDeploy is created. 

Steps to Reproduce:
1.Create an OpenStackDeploy
2.Update OpenStackConfigGenerator and apply it (may or may not need to inject a failure into the config)
3.Apply OpenStackDeploy with updated config hash
4. Error seen in OpenStackDeploy log

Actual results:
```---
I0824 05:03:45.169456       1 deploy.go:323] Running deploy command.
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted
Cloning into '/home/cloud-admin/work/n5cbh54ch697h57bh56h664h648hbdh696h5ddh94h8fh67h59fh685h594hdbh65h57bh5f7h68dh559hb6hddh5bh588h75h695h5d7h5f4hch56q/playbooks'...
Bad owner or permissions on /home/cloud-admin/.ssh/config

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
panic: command terminated with exit code 128
---```

Write permissions on group were added to the contents of the ~/.ssh directory for user cloud-admin:

```---
sh-4.4$ ls -lah
total 24K
drwxrwsr-x.  2 cloud-admin cloud-admin 4.0K Jul 11 15:09 .
drwxrwsr-x. 12 root        cloud-admin 4.0K Jul 18 10:15 ..
-rw-rw-r--.  1 cloud-admin cloud-admin   56 Jul 16 23:33 config
-rw-------.  1 cloud-admin cloud-admin 3.2K Jul 16 23:33 id_rsa
-rw-rw-r--.  1 cloud-admin cloud-admin  725 Jul 16 23:33 id_rsa.pub
-rw-rw-r--.  1 cloud-admin cloud-admin  744 Jul 11 15:24 known_hosts
sh-4.4$
---```

Expected results:
Completion of OpenStackDeploy and NO write permissions on group were added to the contents of the ~/.ssh directory for user cloud-admin:

```---
sh-4.4$ ls -lah
total 24K
drwxrwsr-x.  2 cloud-admin cloud-admin 4.0K Jul 11 15:09 .
drwxrwsr-x. 12 root        cloud-admin 4.0K Jul 18 10:15 ..
-rw-r--r--.  1 cloud-admin cloud-admin   56 Jul 16 23:33 config
-rw-------.  1 cloud-admin cloud-admin 3.2K Jul 16 23:33 id_rsa
-rw-r--r--.  1 cloud-admin cloud-admin  725 Jul 16 23:33 id_rsa.pub
-rw-r--r--.  1 cloud-admin cloud-admin  744 Jul 11 15:24 known_hosts
sh-4.4$
---```


Additional info:
Devs noted the following kubernetes behaviour may be culprit:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods