-
Notifications
You must be signed in to change notification settings - Fork 484
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
RFE: Network+Device trust: Spire Agent EAP(oL) Device Attestation #4281
Comments
What is SpireServerFDO? I'm a little bit lost on all the info here and feel like there's some larger context that I'm missing. I am familiar though with EAP et al. It's not technically agentless since usually you still need a supplicant running? 😅 Personally speaking, I'd only reach for EAP if I was trying to protect L2 network access, which is not a goal for SPIRE ... SPIRE is cloud native software and operates at the application layer. I'm having a hard time coming up with solutions on how to use SPIRE to back an EAP handshake .. and also the value of doing so. I don't think SPIRE will change to speak EAP or 802.1x directly. Why are the existing SPIRE mechanisms insufficient? |
Hi @evan2645,
Thanks in advance :) |
That would be great! I think it will help a lot. My recommendation is to join the SIG-SPIRE call .. the next one is scheduled for next Thursday the 20th, at 10:30am Pacific. Anything you can bring to share and set context (diagrams, slides, etc) would be super helpful, but it is an informal call so don't worry too much. |
@evan2645 awesome :) |
Awesome! That date works, I can help to make sure you have time on the agenda. If you can join the Slack and send me a DM, that would also be great: https://slack.spiffe.io I'm going to go ahead and close these issues out for now, and we can re-open them once we talk, if it makes sense. Thanks again, looking forward to it! |
|
Roots of trust:
This RFE is regarding 3+4. Network+Device based root of trust (B below):
A. XIoT Onboarding: Manufacturer produces device + forwards ownership to company using SpireServerFDO + CaptivePortal
B. XIoT attestation: agentless EAP(oL) device (-> AP) -> SONiCSpireAgentEAP(L2) -> SpireServer -> SONiCSpireAgent(P)NAC/ACL:
-- 802.1x EAP(oL)-TLS X.509 certificate check
-- TPM_Certify_Info(2) (PCR status): Firmware version, BootLoader, OS version, firewall enabled, antivirus enabled, ...
--- Additional Keylime functionality? into upstream
--- MUD (Manufacturer Usage Description) -> ITAM -> XIoT identification
--- SBOM (SoftwareBillOfMaterial) -> ITAM -> continuous lightweight vulnerability scanning -> proactive remediation actions
-- (P)NAC/ACL: SpireServer -> SONiC NAC
C. Company provisions validated devices to their desired state
D. Day2 operations (Realtime Spire Network+Device+User+Workload+Data attestation)
I have given my free OSS GoldenPath KubernetesNative version of a GitOps Zero-Conf|Trust|Touch XIoT management target architecture - directly from network devices.
Suggestions/enhancements would be highly appreciated :)
Thanks in advance :)
The text was updated successfully, but these errors were encountered: