Comments (13)
@portersrc really good point about the repository. Maybe we should just use the repository field of the resource URI to select which repository backend you want to use. We could assign default
to be localfs.
If we don't do that we should rename the Repository trait because it is potentially confusing.
from trustee.
Thanks for the writeup, the plugin architecture sounds intriguing and something that could evolve into a notion of a "virtual resource" as an abstraction over all sort of confidential resources. At the moment, pragmatically, such a resource simply maps 1:1 to a file on a local fs, without much regard to (distributed) state management yet.
re 3) Since this is rather invasive change and probably not something that could be introduced in the short term, have you considered implementing a specific API service to generate those ad-hoc secrets? It could be enlightened to support KBS attestation-tokens (by using KBS code as a library) to support remote attestation via RCAR.
from trustee.
This is an interesting point. Supporting Nebula CA seems to represent a broader need for KBS, that is, after a successful RCAR protocol, the trustee needs to return a certificate to the client. The endorsement of this certificate comes from the TCB of user/trustee. Then Nebula could use the certificate to work as key-exchange/TLS cert to encrypt data flow between pods. For other scenarios, for example, this cert could be used as a "client identity" to access resources.
from trustee.
It seems likely that we'll need to support more than just the localfs backend in the longterm. Currently we allow people to swap out localfs for something else at build time, but nothing else is supported and you can only have one backend. We will probably want some framework for supporting different types of resources at the same time. As @cclaudio suggests we could also extend the KBS protocol to cover things other than resources, but I think it's probably easiest/more scalable to treat everything as a resource.
If we can settle on a framework, we could use that as a basis for building PKI. I'm not sure if Nebula will be able to piggy-back on a generic PKI implementation or if it would still need its own plugin.
from trustee.
xynnn007, "For other scenarios, for example, this cert could be used as a "client identity" to access resources."
(We had a similar train of thought when looking at this; could be appealing, but we've tabled it for now.)
mkulke, "re 3) ... Implementing a specific API service to generate those ad-hoc secrets ... enlightened to support remote attestation via RCAR."
Can you clarify a bit here? This looks non-trivial to me, at least compared with cclaudio's extension of the KBS resource structs and functions. At first I imagined you meant that the same token from the KBS could be reused to fetch more resources from this new nebula service; but maybe you mean that this new nebula service would just have similar RCAR facilities (and a new session and token) when a workload wants to connect to it and join the secure mesh; or maybe it's something else you have in mind?
fitzthum, "It seems likely that we'll need to support more than just the localfs backend in the longterm. Currently we allow people to swap out localfs for something else at build time, but nothing else is supported and you can only have one backend. We will probably want some framework for supporting different types of resources at the same time."
There's a curiosity in the code related to this exact comment. "Repository" takes on two different meanings. There's a "Repository", which is a trait/interface here; but there's also a "repository" passed to get_resource
in the URI (see here), and which ultimately is used as part of the path in the local-fs here. fitzthum's raising a good point: We can only support local-fs right now, but how would we support different types of resources? It seems this support is almost baked into KBS already, except that the repository that's grabbed from the URI needs to actually be used to select a different repository (not some folder in the local-fs's path); and executing repository.read should read from that user-provided repository. This is in the spirit of cclaudio's implementation option (1), and potentially without the need to burn the first URI field with the string "plugin" (and instead just use "nebula" or whatever is desired there).
from trustee.
xynnn007, "For other scenarios, for example, this cert could be used as a "client identity" to access resources."
(We had a similar train of thought when looking at this; could be appealing, but we've tabled it for now.)
Sounds good. Maybe we could start this thread again. Logically, once initdata is implemented, we could have a way to inject something into the guest to work as a client id for registering a certificate. Hopefully we could get a converge on the design of this : )
@portersrc really good point about the repository. Maybe we should just use the repository field of the resource URI to select which repository backend you want to use. We could assign
default
to be localfs.If we don't do that we should rename the Repository trait because it is potentially confusing.
I agree. Storage
, KVStore
or something else might be better. And a good point is that we could have some more configurations for KBS to make different resource path to link to different backend.
from trustee.
Related Issues (20)
- ERROR actix_http::h1::dispatcher] stream error: request parse error: invalid HTTP version specified
- KBS: Be more tolerant to policy rego files HOT 2
- Q RVPS: Should reference values always be hashes? HOT 2
- Expose init_data to policy HOT 2
- AS | Use hex encoding rather than base64 in parsed claims HOT 1
- KBS: session panic HOT 1
- Staged images and release images have different names HOT 1
- kbs: customize OPA policy when deploy KBS HOT 6
- How to provide alignment between Trustee and kbs-operator HOT 1
- KBS: Add a `Delete` method to /resource/{repository}/{type}/{tag} HOT 5
- AS: accessing configuration from verifiers HOT 3
- AS/Verifier: Support quote verification in multi-thread in tdx under high concurrent load HOT 1
- Rename Container Image Build Process from gRPC to RESTful
- kbs: Add support for configurable policy
- Using go instead of rust to implement trustee ? HOT 3
- AS: PolicyEngine should differentiate user and internal errors
- AS & RVPS | Proposal for an attestation applied policy format HOT 7
- Release cadence? HOT 4
- AS: tdx-quote verification unit test fails HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trustee.