updating RFC with updated discussion/comments

[gaelcolas]

This PR is to update my draft RFC with suggestions and discussions from @Jaykul, @jpogran, @TravisEz13.

• Do not handle PsDscRunAsCredential as part of that command (but provide a script showing a proxy doing so in the PS Gallery). It should just not be handled by the Invoke-DscResource function.
• Clarify Output for Get/Set/Test to be consistent with WMF 5.1 in terms of property (but no CIM class)
• Clarify DSC Resource parameters (no need for CIM types, but still recommended for backward compatibility)

[thedevopsmachine]

Instead of removing a very important feature and replacing it with a simple link to unsupported third party code, you could do what every other .NET cross-platform library does and throw a "PlatformNotSupported" exception if you try to use that feature on a Mac or Linux machine. Or just ignore those parameters on that platform. It makes no sense to cripple your entire existing user base to support a tiny portion of your potential future user base.

Alternatively, you could make an "Invoke-DscResourceAs" Cmdlet that wraps the new "Invoke-DscResource" Cmdlet and does all that RunAs stuff for you. Saying that "it's up to the agent to implement this" will lead to a different implementation for every agent, which means that resources that work in one agent may not work in another.

[gaelcolas]

you could do what every other .NET cross-platform library does and throw a "PlatformNotSupported" exception

Technically we could, but I don't think that's a good approach for something that has to be supported for as long as PS7 is.

you could make an "Invoke-DscResourceAs" Cmdlet that wraps the new "Invoke-DscResource" Cmdlet and does all that RunAs stuff for you

yeah, that's exactly what I have in mind, when I say:

[...] and instead will try to publish a wrapper on the PS Gallery

But I'm also considering that:

1. Making this part of PS7+ is a bad choice, I think it should probably be packaged in a separate and independent module/script that is easier to improve, replace, or deprecate and get rid of eventually. Also, we can make that module/script to fail to load if not in windows ($IsWinodws -> throw PlatformNotSupported).
2. There is several implementations possible, even when only considering Windows. Something like PSThread Job could provide enough isolation for using impersonation within a thread. Having something developed independently & in the open, with third parties & vendors contributing to it, would make it evolve quicker, and avoid the multiple implementations. That is still out of scope for this RFC though (but could potentially be another one).
3. I don't want this to be slowing down or blocking the core functionality as per the MVP this RFC is attempting to address.

Ideally, PowerShell would have something like PSThreadJob built-in, with cross platform support for runAs, then it would make sense to have Invoke-DscResource to leverage that.

[thedevopsmachine]

One thing I don't think is being taken into consideration is "why do people want to use RunAs?" You use PSDscRunAsCredential because you need to use Kerberos to authenticate to an external service/resource, e.g. a SMB file share, Active Directory, a Windows Cluster node, a SQL Server etc.

On Windows, Kerberos is this magical thing that just happens when you log in as a user.

On Linux/Mac, Kerberos is implemented via keytab files. The root user can access any of these files, so all it needs to do is the run kinit using the RunAs user's keytab file. Using PSJobs doesn't actually solve your problem since you'd need to do the kinit stuff anyway.

But before we go further down this path, let's ask the question, when does a Linux machine ever actually need to use Kerberos? Take a look at all of the DSC resources that require Kerb. Windows Clusters, Storage Spaces Direct, SQL Server (only with Windows auth), Sharepoint etc. Notice what they have in common? They're all Windows-specific resources. What's your use case for RunAs on Linux? Is meeting that use case so important that it justifies ignoring all your other use cases?

Moving it to a separate module that doesn't ship with Windows is a pain because it means that I have to download things onto my machine in order to execute DSC. Since I can't use DSC for this, I'm now writing build scripts again, which is what DSC is designed to eliminate. I also have another module to deploy and manage across my entire fleet. I either need internet access to public PSGallery, a private PS gallery, or a open file share from which I can download it if I don't have internet access. I don't understand how introducing so much extra pain for your customers so that they can do what they already do today is "the right choice". Seems like a big step backwards to me.

"I don't think that's a good approach for something that has to be supported for as long as PS7 is." - you don't have to release everything on day 1. You can use windows update etc. to deploy new functionality, on Day 1 you can support your biggest use case (Windows) and on Day x you can deploy new code that will support Linux and Mac. So just because PS7 needs to be supported for a long time, it doesn't mean that we can't add features and fix bugs after the initial release.

[thedevopsmachine]

This is not true. PowerShell is written in .NET, and .NET has a class that can identify what platform you're running on. Then you can do an if/else check, if Windows then use existing runas code for Windows, if Linux then throw PlatformNotSupported exception (or just strip the parameter). Just because Linux/Mac doesn't support a feature, doesn't mean you should remove it. Just remove it for the platforms that don't support it.

[gaelcolas]

PlatformNotSupported on Linux/MacOS is not what I consider "truly cross platform".
For the core functionality I think it's important to stick with things that behaves the same way in all OSes (be it Jobs for both or not supporting at all in the core command).
We can extend functionalities on a per-os basis by extending (wrapping) functionalities as we suggested.
I agree that using Jobs for both is a bad idea in terms of performance on Windows (i.e. could be much better with impersonation), and it poses the problem of consistency (when you run as current user without job, or as another user), that's why I don't want it built-in either.

[gaelcolas]

Thanks for the comments @thedevopsmachine,

I do agree that this part should probably be removed:

In the end, this is very much an Agent feature, and each agent author may want to
(and already do) support this themselves, so it's unnecessary code and complexity
for them.

It does not set the right mindset.

At the same time, I don't want (or can't), commit to anything else in this RFC as it's out of scope and should probably come after and be another one.

I'll definitely raise this up and discuss it internally though.