Project

General

Profile

action #104751

Extend "_SECRET_" variable handling to os-autoinst backend password variables

Added by okurz 7 months ago. Updated about 9 hours ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Feature requests
Target version:
Start date:
2022-01-10
Due date:
2022-01-24
% Done:

0%

Estimated time:
Difficulty:

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?

Related issues

Related to openQA Project - coordination #105624: [saga][epic] Reconsider how openQA handles secretsNew2022-01-25

History

#1 Updated by cachen 7 months 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.

#2 Updated by okurz 7 months ago

  • Description updated (diff)

#3 Updated by okurz 7 months 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

#5 Updated by okurz 7 months ago

  • Status changed from New to Feedback
  • Assignee set to okurz

#6 Updated by okurz 7 months 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

#7 Updated by okurz 7 months 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.

#8 Updated by cachen 7 months 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?

#9 Updated by cachen 7 months ago

  • Priority changed from Low to High

Change back the priority to high, it was changed by accident.

#10 Updated by cachen 7 months 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!

#11 Updated by nicksinger 7 months ago

#12 Updated by nicksinger 7 months ago

#13 Updated by nicksinger 7 months ago

#16 Updated by okurz 19 days ago

Thank you for bringing that up. We will crosscheck in #114766

#17 Updated by Julie_CAO 8 days 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?

#18 Updated by cdywan 8 days 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

#19 Updated by Julie_CAO 8 days 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.

#20 Updated by okurz 4 days 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.

#21 Updated by cachen 1 day 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?

#22 Updated by okurz 1 day 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.

#23 Updated by cachen about 24 hours 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.

#24 Updated by okurz about 14 hours 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".

#25 Updated by cachen about 9 hours 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'.

Also available in: Atom PDF