action #104751
closedExtend "_SECRET_" variable handling to os-autoinst backend password variables
Added by okurz over 2 years ago. Updated about 2 years ago.
0%
Description
Motivation¶
We already don't write any variable with "SECRET" in the name to vars.json for security reasons. Within os-autoinst we have some security relevant data, e.g. passwords that we should likely treat the same.
Acceptance criteria¶
- AC1: Remote backend passwords don't appear in vars.json by default
Suggestions¶
- Call
git grep '_SECRET_'
to find all current handling of SECRET variables - Extend that to also look for
_PASSWORD
- Ensure that the values for the backend passwords don't show up in vars.json, e.g. no IPMI_PASSWORD entry as in https://openqa.nue.suse.com/tests/7924361/file/vars.json
- Consider what happens when cloning such jobs. Do they fail because the password is missing?
Updated by cachen over 2 years ago
Thank you Oli, would it be possible raise priority for this ticket?without this done, I am afraid, we are not able to take action to change our test machine settings with new secure password for Asset security need.
Updated by okurz over 2 years ago
- Tags changed from easy, os-autoinst, secret, security to os-autoinst, secret, security
- Subject changed from [easy] Extend "_SECRET_" variable handling to os-autoinst backend password variables to Extend "_SECRET_" variable handling to os-autoinst backend password variables
Updated by okurz over 2 years ago
- Status changed from New to Feedback
- Assignee set to okurz
Updated by okurz over 2 years ago
- Due date set to 2022-01-24
- Priority changed from Low to High
Given the implementation shouldn't be too hard and the above PR is already present I think we can treat this with high prio
Updated by okurz over 2 years ago
- Description updated (diff)
- Status changed from Feedback to Resolved
As visible for example in https://openqa.suse.de/tests/7971958/file/vars.json newer jobs don't reveal any PASSWORD variable in vars.json anymore.
@cachen @Julie_CAO if you like you can continue with changes to the passwords.
Updated by cachen over 2 years ago
- Priority changed from High to Low
okurz wrote:
As visible for example in https://openqa.suse.de/tests/7971958/file/vars.json newer jobs don't reveal any PASSWORD variable in vars.json anymore.
@cachen @Julie_CAO if you like you can continue with changes to the passwords.
Hello Oli, thank you for your great job! I have noticed the PR was merged and already effected in the example successfully hide HMC_PASSWORD,it should also works for IPMI_PASSWORD which is in same var format.
However I just found IPMI_PASSWORD is still visible in the test http://openqa.qa2.suse.asia/tests/43469/file/vars.json which was finished in couple minutes ago, our local openQA both worker and webui have been upgraded to the latest yesterday and I checked this PR code is in there. Is there anything missed in our deployment? Would you please help to take a look?
Updated by cachen over 2 years ago
- Priority changed from Low to High
Change back the priority to high, it was changed by accident.
Updated by cachen over 2 years ago
cachen wrote:
okurz wrote:
As visible for example in https://openqa.suse.de/tests/7971958/file/vars.json newer jobs don't reveal any PASSWORD variable in vars.json anymore.
@cachen @Julie_CAO if you like you can continue with changes to the passwords.
Hello Oli, thank you for your great job! I have noticed the PR was merged and already effected in the example successfully hide HMC_PASSWORD,it should also works for IPMI_PASSWORD which is in same var format.
However I just found IPMI_PASSWORD is still visible in the test http://openqa.qa2.suse.asia/tests/43469/file/vars.json which was finished in couple minutes ago, our local openQA both worker and webui have been upgraded to the latest yesterday and I checked this PR code is in there. Is there anything missed in our deployment? Would you please help to take a look?
Apologize! The PR also effects in Beijing local openQA, IPMI_PASSWORD is not visible in in the test http://openqa.qa2.suse.asia/tests/43469/file/vars.json, the showing PASSWORD is for system in this case.
Thank you Oliver again!
Updated by nicksinger over 2 years ago
- Copied to coordination #105624: [saga][epic] Reconsider how openQA handles secrets added
Updated by nicksinger over 2 years ago
- Copied to deleted (coordination #105624: [saga][epic] Reconsider how openQA handles secrets)
Updated by nicksinger over 2 years ago
- Related to coordination #105624: [saga][epic] Reconsider how openQA handles secrets added
Updated by okurz about 2 years ago
Thank you for bringing that up. We will crosscheck in #114766
Updated by Julie_CAO about 2 years ago
okurz wrote:
Thank you for bringing that up. We will crosscheck in #114766
Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?
Updated by livdywan about 2 years ago
Julie_CAO wrote:
Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?
Please try again now
Updated by Julie_CAO about 2 years ago
cdywan wrote:
Julie_CAO wrote:
Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?
Please try again now
Thank you, @cdywan. I can access it now.
Updated by okurz about 2 years ago
Julie_CAO wrote:
… tell me when the issue will be fixed?
We do not currently plan to work on #114766. We leave it to others to work on this.
Updated by cachen about 2 years ago
okurz wrote:
Julie_CAO wrote:
… tell me when the issue will be fixed?
We do not currently plan to work on #114766. We leave it to others to work on this.
@okurz can you please give an ETA? and Who is the others?
@jstehlik for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?
Updated by okurz about 2 years ago
cachen wrote:
okurz wrote:
Julie_CAO wrote:
… tell me when the issue will be fixed?
We do not currently plan to work on #114766. We leave it to others to work on this.
@okurz can you please give an ETA? and Who is the others?
ETA for us would be weeks-months. Everyone else is the "others". As this is concerning code only within os-autoinst within special backends it is easier for people not within the SUSE QE Tools team, e.g. you or your team, to contribute this without needing to understand more complicated details like communication between the openQA worker and the backend.
@Jan Stehlík for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?
In all honesty, the rest of the company can work following "factory-first", it's the core of SUSE's business model and everyone joining SUSE should have that as motivation. It is not the first time you make statements like "we can work until issue XYZ is fixed". If you feel you definitely need a certain thing then you should not rely on other teams to do that for you. Here in the case of some problem specific to the IPMI backend I am confident you can solve that problem within your team with a reasonable amount of work. Let me remind you that for years development of virtualization packages has been going on and existing virtualization tests within openQA based on the qemu backend provide helpful feedback so a viable alternative is always to look further in this area not necessarily needing bare-metal based tests for the complete validation of all relevant features.
Updated by cachen about 2 years ago
okurz wrote:
cachen wrote:
okurz wrote:
Julie_CAO wrote:
… tell me when the issue will be fixed?
We do not currently plan to work on #114766. We leave it to others to work on this.
@okurz can you please give an ETA? and Who is the others?
ETA for us would be weeks-months. Everyone else is the "others". As this is concerning code only within os-autoinst within special backends it is easier for people not within the SUSE QE Tools team, e.g. you or your team, to contribute this without needing to understand more complicated details like communication between the openQA worker and the backend.
@Jan Stehlík for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?
In all honesty, the rest of the company can work following "factory-first", it's the core of SUSE's business model and everyone joining SUSE should have that as motivation. It is not the first time you make statements like "we can work until issue XYZ is fixed". If you feel you definitely need a certain thing then you should not rely on other teams to do that for you. Here in the case of some problem specific to the IPMI backend I am confident you can solve that problem within your team with a reasonable amount of work. Let me remind you that for years development of virtualization packages has been going on and existing virtualization tests within openQA based on the qemu backend provide helpful feedback so a viable alternative is always to look further in this area not necessarily needing bare-metal based tests for the complete validation of all relevant features.
@okurz, 2 things in your statement are true: we should motivate to 'factory first'(so we invest); my team has technical ability to do it(thanks I have a powerful team). But let me point we all have agreed backend(not just qemu) of openQA are responsible by QE-tools team, so VT squad expects to have tools team's support is reasonable(we have got many support, thank you), and team co-work is needed because each team/individual has their responsibility, it doesn't means "I am a supper man, I can/should do everything". So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.
Updated by okurz about 2 years ago
cachen wrote:
So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.
Sure, it can happen that nobody else feels capable to do so and that's fine. So then it's back to "currently not planned".
Updated by cachen about 2 years ago
okurz wrote:
cachen wrote:
So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.
Sure, it can happen that nobody else feels capable to do so and that's fine. So then it's back to "currently not planned".
It's fine and understandable if Tools team no capable for it in current due to others more urgent tasks, as long as you take it fairly the priority in backlog, as it's a security relevant and pending to others, and like you said it's 'easier for people'.
Updated by okurz 7 months ago
- Related to action #156016: [openQA][sle-micro][virtualization] Test slem_virtualization@uefi with Default-encrypted image was not triggered correctly size:M added