SPIRE Agent Windows Support

[colek42]

The SPIRE Agent should be extended to support attestation of Windows workloads. The current version of Windows supports UDS natively as of Windows 10 as of build 1809. @azdagron Has done a POC using named pipes.

• What are the introspection capabilities through named pipes/windows UDS?
• How much does support of Windows users before build 1809 matter?
• User experience for OS-specific plugins, i.e. UNIX workload attestor.

• Version: n/a
• Platform: Windows
• Subsystem: Agent

[evan2645]

I don't have many answers, but I have some thoughts/observations :)

How much does support of Windows users before build 1809 matter?

We could always start with UDS, and build support for other transports later on if we deem it necessary. One important thing to keep in mind is that if we introduce any transport other than TCP or UDS (e.g. named pipes), then we will need a change in the SPIFFE spec, which will take time.

User experience for OS-specific plugins, i.e. UNIX workload attestor.

I'd like to suggest that we detect this at startup, and bail out.

This brings up another point which is, if we are going to launch windows support, we'd better have at least one attestor that works with it! So that work is probably in scope too.

@amartinezfayo has a bunch of other thoughts here too on scope and what all we'll need in order to support windows properly

[colek42]

Support for Windows AF_UNIX was added in Go - https://go-review.googlesource.com/c/go/+/125456

[azdagron]

Importantly, we'll also need support for the SO_PEERCRED socket option (or a Windows equivalent mechanism) to introspect the PID from the caller.

[azdagron]

(SO_PEERCRED is not defined for Windows in Go's syscall package, I haven't tried to call this on Windows, myself)

[colek42]

Seems relevant: golang/go#41659

[colek42]

@bradfitz looks like he is doing some work on this -- https://github.com/inetaf/peercred/blob/main/peercred_linux.go#L24 he may have some insight.

Looks like grabbing the connection info from the TCP connection table might be a suitable path.

[amartinezfayo]

Thanks @colek42 for opening this issue!
Having Windows support in SPIRE is something that I personally think that would be very beneficial for the project, opening new avenues to grow the adoption of the project. I have the feeling that once we introduce at least a minimum support, we will start a path of more and more integrations with Windows.

The open questions raised are maybe the most important things to start looking at when considering this. At the same time, I think that there are some other aspects that need attention and should be part of the scope of this effort, so we don't miss them from the complete picture. Here are some thoughts:

• Deployment
  There are different methods that may be supported, like just downloading the binary, use a package manager, an installer, etc. We should also think about how default paths are affected, including deployed config files.

• Privileges required
  We need to figure out if the process running SPIRE Agent would need a special privilege that a non-admin user may not have.

• SPIRE Agent as Windows service
  It may be desirable to run the agent as a Windows service. We need to consider if we may need to support registering it as a service.

• Development experience
  Once we start supporting Windows in a way, developers will need to build it on Windows. We need to adapt our build tooling to support Windows.

• Changes needed in the CI
  Consider the changes in the CI configuration to support building the Windows binary.

• Documentation
  All the documentation that we have assumes Linux/Mac OS. We will need to update it as appropriate. I think that it will also be important to make a clear note of what is supported in Windows and what is not.

• Plugins supported
  As mentioned by @evan2645, I think that at least one built-in workload attestor should be supported on Windows from the beginning, otherwise the support would be very confusing.

[amartinezfayo]

I forgot to mention that I would be very happy to help here :)

[ricardf]

We have some use casses that we could use the agent on windows to start using the project as for now we need to go for other solutions as we have linux/windows scenarios where we want to use the spire implementation.

[amartinezfayo]

@ricardf Thanks for your interest!
Could you elaborate on the use cases that you have? We are on the early stages of scoping the work, so knowing the details of your use cases would be very helpful.

[colek42]

I'd like to use SPIRE to provide certs to in-toto on windows build machines.

[ricardf]

@ricardf Thanks for your interest!
Could you elaborate on the use cases that you have? We are on the early stages of scoping the work, so knowing the details of your use cases would be very helpful.

Being able to deploy the agent and the helper into windows would allow to create different scenarios on windows.

One example can be on a kubeedge example:

We have scenarios where the applications components is on windows, so at the moment we can run ghosttunnel on windows but not the helper.

I haven't tested, but it seems that envoy.exe could be used as a windows service, so this scenario could be possible in windows if we had the agent running on windows:

[Falco20019]

We are also interested in this. We are using C# as our main language. We can't run Docker/K8s in the customer on-premise environment and are forced to use Windows. We can talk to UDS through gRPC on C#, so making a helper using the Workload API shouldn't be a big issue. So the only blocking stone is getting SPIRE Server and SPIRE Agent for Windows :)

[amartinezfayo]

Thank you @ricardf for your detailed explanation.
I'm in the process of doing an in-depth research of all the different aspects involved for this, like if a change in SPIFFE specifications would be needed or can be avoided, etc.
I'm curious to know if you are already using SPIRE in environments that are supported today, or if running SPIRE on Windows would be your first experience with SPIRE.