-
Notifications
You must be signed in to change notification settings - Fork 271
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
Accept Datatype Sensitive for all Secrets #960
Accept Datatype Sensitive for all Secrets #960
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't really reviewed it in depth. Please don't align parameters.
Other than that I am open to it. We'll need to verify if our installer handles it properly and otherwise patch that.
I do feel like a Puppet function to unwrap if needed makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to prefer this in separate PRs. The reason is that I don't know if our installer handles Sensitive well. Another is that we have some tools that read the sensitive values from our answers. For example, they read a DB password. I'm not saying this is good, but it's a concern that we need to address. Consider it a heads up that this is not a trivial merge for us.
So I'd say that the first one is converting templates from ERB to EPP. This is IMHO an easy PR to merge since it remains compatible.
Then dealing with Sensitive. Perhaps a way to mitigate our installer concerns is to first make sure the module handles Sensitive everywhere but keep defaulting to regular strings. This would allow users of the module to pass in sensitive values while not breaking our installer.
Then a third could be defaulting to Sensitive values.
I also have no experience with Sensitive myself. Whenever I tried it, I found it be quite useless given that you still need to unwrap in many places. I also don't know how well it works with Hiera.
As a last one - should we also change files with sensitive values to show_diff => false
?
That sounds like a Plan. So, we close this PR now, and I'll create separate PRs then. Okay?
Exactly this is the main Driver for my Effort. Code with or without
Not sure, if I understand You right. With
In my Environment the Secrets come from Hashicorp Vault using a Function like |
This part is now merged. Do you want to rebase this PR or open a new one? |
I will rebase. |
Rebasing done. |
Looks like something went wrong in the rebase because I see some unrelated commits that are already in master. Also has more conflicts now. |
I squashed and repaired my Branch. |
manifests/cli.pp
Outdated
# epp() returns a Content of Datatype Sensitive, if at least one Parameter is of Datatype Sensitive. | ||
# The "unwrap" therefore is not necessary, BUT: I do not know, how to make the Test pass in | ||
# spec/classes/foreman_cli_spec.rb:110 otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps #976 would help with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this now be resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the Comment and the unwrap
, but did not manage to establish a Rspec-Test.
I amended the Commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took a while to circle back to this, but I still see this as a good enhancement and I'd like to see this finished.
manifests/cli.pp
Outdated
# epp() returns a Content of Datatype Sensitive, if at least one Parameter is of Datatype Sensitive. | ||
# The "unwrap" therefore is not necessary, BUT: I do not know, how to make the Test pass in | ||
# spec/classes/foreman_cli_spec.rb:110 otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this now be resolved?
- accept Datatype Sensitive for Puppet-Type foreman_config_entry - accept Datatype Sensitive for CLI-Password - accept Datatype Sensitive for initial Admin-Password - accept Datatype Sensitive for Database-Password - accept Datatype Sensitive for OAuth-Secrets - accept Datatype Sensitive for SMTP-Secrets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Thanks for the big effort.
Sadly it looks like what we were afraid of is true: Kafo doesn't understand the Sensitive data type so it breaks: https://community.theforeman.org/t/foreman-installer-develop-package-release-1035-failed/26898 I'll see about a fix. For inspiration, do you know what's best practice with regards to Hiera? |
Sure. |
Right now it's failing on parsing the data types for its own validation. We have a list of data types: |
Probably ok. I've used |
Technically I suppose we can implement it as a transparent container. I might have a try. |
I took a stab at it: theforeman/kafo#345. I haven't tested it end to end, but at least it recognizes the type. I also submitted #1018 which I think should close the loop. |
:username: '<%= $username %>' | ||
:password: '<%= $password %>' | ||
:username:<%= if $username { " '${username}'" } %> | ||
:password:<%= if $password { " '${password}'" } %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow this doesn't work for me. In #1018 I'm adding a test, but doesn't unwrap the string. I also checked if it perhaps was the interpolation, but that also doesn't appear to be it.
No description provided.