-
Notifications
You must be signed in to change notification settings - Fork 483
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
Setting metadata value with a secret/variable fails in the end_user_authentication section #26135
Comments
Hey team! Please add your planning poker estimate with Zenhub @dantecatalfamo @jacobshandling @lucasmrod @sgress454 |
I wouldn't be surprised if this was due to the contents of the variable, rather than an issue with using a variable for this config. |
@allenhouchins can you DM and let me know how you're setting the env var when testing #26042? |
I was going to put this update in #26387 but probably makes more sense to put here with the original issue. The part that still isn't clear is why this specific multiline variable works in other places in the same yaml file. Have we gotten to the root cause of why this variable works in The admin/user expectation is that they can copy settings from one place (like the SAML metadata in Google) to another place (like their GitHub secret) and it works without further manipulation since that is what they would be doing in the UI. We also can't have an admin further edit this data before making it a secret because then it won't be compatible with the IdP. This issue seems to be very specific to CC: @noahtalerman for awareness. |
Hey @sgress454 I agree with Allen here. I don't think we want to ask the user to tweak the metadata they download from Google Workspace. They should be able to download the metadata, paste it into a GitHub env variable (or the UI), and boom they're ready to go. If that's not working, the fix here is to make that work. |
Yes -- the issue is that the value of the
I don't agree with the "that is what they would be doing in the UI" part -- if you pasted something from Google into the UI and didn't adjust the indentation to be correct, it would fail. YAML is pretty strict about that, and we don't do any auto-fixing in the UI -- we just complain:
I can't speak to Google Workspace, but whoever set up the |
I think the argument would be if it failed in the UI, then that means we didn't build it correctly to meet the expectation of being able to copy and paste from the IdP into our product. Again, that information can't be manipulated just to be accepted by the UI (or gitops) otherwise the IdP is going to reject it when they receive it.
Looking at the value in the UI, which is populated via gitops, you will notice it has all the correct spacing provided by the IdP and is the expected format for SAML metadata xml. Because we aren't auto-formatting these values, the only way it would have gotten this formatting was by copy/pasting it into the secret in this format. |
This is the value we're displaying after having extracted it from the YAML and saving it in the database. If it was originally set via GitOps, it would have been set using correct indentation. It would have had to have been, otherwise it would have been rejected as invalid YAML. I can write an action to output the actual value of the key if we need further proof.
What we have in the UI is a YAML editor, which validates that you have correct YAML. If you paste in a multi-line string that's not correctly formatted, it will let you know. For instance, if I take the metadata from the link above and try to paste it into a multi-line YAML key in the agent options, it will tell me it's invalid until I highlight it and press the tab key until it's in the right spot. I agree it'd be great to be able to tell users that they can paste a key value into a Github secret and use it as-is anywhere in a GitOps file. I'd like for them not have to do |
@sgress454 gotcha. This value was originally set via GitOps. It's If I'm understanding correctly, the @sgress454 do you have access to get the GitHub env variables. If yes, can you please paste both of these in a google doc and share it in Fleet's Google drive so we can check them out? |
My guess is that they're the same value, but the indentation is only right for one of them because they're being used in two different parts of the YAML file which are indented differently. I'll see what I can do re: getting the secret values safely. |
Worked with @sgress454 to get to the bottom of this (thank you!). The issue was related to how the XML in the variable was unfurling and not having the appropriate tabbing for yaml-compatibility. So it's working as expected but documentation could use some improvements (I'll take this on) and I will also be submitting a Feature Request to be able to figure out how admins can just copy and paste the SAML metadata into a secret without having to properly tab it for unfurling into yaml. |
Metadata fails, yet |
Fleet version: 4.63
Web browser and operating system: Any
💥 Actual behavior
I am trying to set a value for metadata via gitops for end_user_authentication using a github secret (ex:
$DOGFOOD_SSO_METADATA
). This results in the error:Error: failed to unmarshal file error converting YAML to JSON: yaml: line 42: could not find expected ':':
This same secret works without issue under the
sso_settings
option. I am also able to get theend_user_authentication
section to work if I paste the contents of that variable as the value (as a string). This issue seems limited to some validation we are doing specifically in theend_user_authentication
section. Setting the values through the UI gives me expected results.🧑💻 Steps to reproduce
🕯️ More info (optional)
See this pull request for the error: #26042
The text was updated successfully, but these errors were encountered: