Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This isn't fully ready to be merged, but I wanted to open this PR to see how you feel about these changes.
I'm trying to migrate from a Google API module my team has written, UMN-Google, to this module. Our primary use case is running from within Azure Automation. Additionally, We're currently using a service account with a .p12 cert to do all our authentication, though our .p12 isn't a super admin, it's just a "regular" user in our domain. Additionally, when we first created our .p12 cert we re-exported it with a new more secure password, instead of
notasecret
.So the first change I've made here is to create a
P12KeyPassword
config item. It can be specified withSet-PSGSuiteConfig
. If it exists,New-GoogleService
will use it instead of the default password. I've constructed it in the way I have such that, if someone doesn't use this parameter, they'll never see it in their config. This also makes it backwards compatible with existing configs, and doesn't require anything like setting thenotasecret
password in every config file.The rest of the changes are because of our primary use case, Azure Automation. First I'll note that I wrote the rest of this before I saw the
Import
andExport
Config commands. So it's entirely possible I could be using those, but at a first glance I don't think they'd fully work in my scenario.Azure Automation has its own secrets management. It can store/retrieve strings. It can also store/retreive a few object types, like
PSCredential
andX509Certificate2
. Because we do all our secrets management in Azure Automation directly, I don't want to have to do any work to store my configuration on the actual machine, and make the deployment of new HybridRunbookWorkers as simple and automated as possible.So first, I've modified the
Get-PSGsuiteConfig
function, specifically the internalDecrypt
function. Now it will "decrypt" one additional datatype, aScriptBlock
. It does this by actually executing the ScriptBlock, which makes the configuration incredibly versatile. I haven't modified the correspondingSet
command for this, because I think it may be advanced enough that someone should have to edit their Configuration by hand if they want to do it.In Azure Automation if I want to retrieve a string value, I would use the command
Get-AutomationVariable -Name <name>
. For example if I stored my App Email in a variable calledgcert-email
thenGet-AutomationVariable -Name 'gcert-email'
in a runbook would return the App Email. Then I can do something like this in my Configuration, making it fully portable:The ScriptBlock construction here is a feature of the Configuration module, when it deseralizes this, the
AppEmail
property will be an actual ScriptBlockTo Decrypt this I added another case, if the
$String
being decrypted is of type[ScriptBlock]
it will execute it and return whatever it returns. In my case it will return an actual string, so the end result is theAppEmail
config item is being set and defined by my Azure Automation Variable.Azure Automation can also produce exportable passwordless certificates, in the same format as your certificate construction code currently takes. So I've added another config that can be retreived with
Get-PSGsuiteConfig
,P12KeyObject
. IfP12KeyObject
is defined,New-GoogleService
will skip trying to write the bytes of the password protected cert, and skip creating the certificate object, and just use the value ofP12KeyObject
directly.The end result of all this is I can write a config file that looks like this:
I've been able to test this in my environment, but that's the extent of testing I've done. I'm opening this to see what you think about this, to determine if I'll put more work into making it merge ready.