3 ms·

It may seem this is snark, but I promise I don't mean it that way: why do you not drink your own champagne? https://github.com/MatrixAI/Polykey/blob/v1.13.0/.gi

It may seem this is snark, but I promise I don't mean it that way: why do you not drink your own champagne? https://github.com/MatrixAI/Polykey/blob/v1.13.0/.github/workflows/release.yml#L106 https://github.com/MatrixAI/Polykey/blob/v1.13.0/.github/wor... I see references to gitlab CI yamls in the source tree, implying you are multi-CI which seems like an extra awesome way to showcase the one source of truth for credentials. Bonus confetti if Ploykey were able to auth as the CI job via https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/security-for-github-actio... or https://docs.gitlab.com/ee/ci/yaml/#id_tokens https://docs.gitlab.com/ee/ci/yaml/#id_tokens

CMCDragonkai 2y ago
Yes, you are right to point this out. We are dogfooding Polykey in our own company's operations, specifically integrating it into all of our team member's NixOS development platforms with the control plane beta PKE (Polykey Enterprise). Using Polykey in the CI/CD situation as you point out in your links is actually one of the major complex usecases we designed Polykey for, however it's actually quite a complex problem domain. We expect to do a sort of "painkiller" phase 1 first where PK is used as the network for sharing secrets, and then a subsequent "vitamin" phase 2 where secrets are no longer shared at all, because authority is delegated through trust federation. Right now PK is a decentralized secret sharing system (every agent is a P2P node), so there's no well-known trust anchor to form a trust federation via OIDC. However once we have PKE ready, then we plan to enable OIDC customer portals within PKE following ideas from https://openid.net/specs/openid-federation-1_0.html https://openid.net/specs/openid-federation-1_0.html (e.g. yourcompany.enterprise.polykey.com). This requires a more sophisticated policy-logic system integrated into each Polykey node's sigchain, atm we have work in progress for public/private network segregation. In our internal documentation, I have a diagram of how PK would integrate into a CI architecture, just haven’t shared it publicly yet. I’ll try to get it out soon. Let me know if you’re interested in more details!

CMCDragonkai 2y ago

Yes, you are right to point this out. We are dogfooding Polykey in our own company's operations, specifically integrating it into all of our team member's NixOS development platforms with the control plane beta PKE (Polykey Enterprise). Using Polykey in the CI/CD situation as you point out in your links is actually one of the major complex usecases we designed Polykey for, however it's actually quite a complex problem domain. We expect to do a sort of "painkiller" phase 1 first where PK is used as the network for sharing secrets, and then a subsequent "vitamin" phase 2 where secrets are no longer shared at all, because authority is delegated through trust federation. Right now PK is a decentralized secret sharing system (every agent is a P2P node), so there's no well-known trust anchor to form a trust federation via OIDC. However once we have PKE ready, then we plan to enable OIDC customer portals within PKE following ideas from https://openid.net/specs/openid-federation-1_0.html https://openid.net/specs/openid-federation-1_0.html (e.g. yourcompany.enterprise.polykey.com). This requires a more sophisticated policy-logic system integrated into each Polykey node's sigchain, atm we have work in progress for public/private network segregation. In our internal documentation, I have a diagram of how PK would integrate into a CI architecture, just haven’t shared it publicly yet. I’ll try to get it out soon. Let me know if you’re interested in more details!