Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use stringData when creating root password secret #920

Merged

Conversation

rabi
Copy link
Contributor

@rabi rabi commented Oct 3, 2024

When using data, NodeRootPassword value should be base64 encoded. If using a normal string for $EDPM_ROOT_PASSWORD secret creation fails.

When using data `NodeRootPassword` value should be base64
encoded. If using a normal string for $EDPM_ROOT_PASSWORD
secret creation fails.

Signed-off-by: rabi <[email protected]>
Copy link
Contributor

@fmount fmount left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@@ -24,7 +24,7 @@ metadata:
name: baremetalset-password-secret
namespace: ${NAMESPACE}
type: Opaque
data:
stringData:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I see everything starts with BM_ROOT_PASSWORD passed as input, that is propagated here.
I don't have big concerns to prefer data over stringData (as we're delegating k8s to encode the secret for us), so I'm ok with the patch if it ease the development workflow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abays FYI ^

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does our CI automation currently use this? I just wonder if they're already passing base64-encoded values through the env var (BM_ROOT_PASSWORD), such that if it was injected into stringData, k8s would try to base64-encode something that was already encoded by the user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, in that case we need to update how CI pass this info as well. @rabi I'm wondering if we want to clarify this aspect before merging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had checked it before proposing. I didn't find it being used in any of the openstack-k8s-operator repos. Unless there is some other places that we should look for.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack, feel free to remove the hold when you're comfortable merging the patch then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abays Do you see this breaking something? If at all something is broken it can be fixed when reported I guess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't know if something in CI is using this already or not. It just seems possible to me that some existing job automation might be setting BM_ROOT_PASSWORD as an encoded string already. Maybe we should ask someone on the CI side to comment? @raukadah, maybe you know something about this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see it being used in upstream/downstream CI.

Copy link
Contributor

openshift-ci bot commented Oct 3, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fmount, rabi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Oct 3, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit 60827c3 into openstack-k8s-operators:main Oct 4, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants