-
Notifications
You must be signed in to change notification settings - Fork 82
implement plugin authentication, finer-grained restrictions/validation. #183
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
base: main
Are you sure you want to change the base?
Conversation
d47b6d6
to
34a751d
Compare
34a751d
to
1e28cf6
Compare
1e28cf6
to
3997cb8
Compare
c7f97fc
to
99fec92
Compare
99fec92
to
63d8c5d
Compare
pkg/adaptation/plugin.go
Outdated
} | ||
|
||
p.role.algo = algo | ||
chal, key, err := p.role.algo.Challenge([]byte("XXtmpXXX"), req.PublicKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Judging by the name, I'm assuming this will be replaced? Should this be a random seed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Argh... that was already supposed to be replaced by a random seed. Thanks for spotting it !
63d8c5d
to
cceb324
Compare
cceb324
to
8fe3f62
Compare
Neither assume that we have a single proto definition nor hardcode proto file locations for post-processing actions based on such an assumption. Signed-off-by: Krisztian Litkey <[email protected]>
Add a service and protocol for challenge-response authentication. Define an interface for authentication implementations. Implement a default authentication, mostly based on the ideas described in containerd#152, the proposal for plugin authentication. Add examples/keygen.go for generating key pairs for this default implementation. Signed-off-by: Krisztian Litkey <[email protected]>
Add optional authentication-related information to the list of plugin instances for validation. This should allow finer- grained validation including loser or stricter restrictions for authenticated vs. unauthenticated plugins. Signed-off-by: Krisztian Litkey <[email protected]>
Add a new option for acquiring a public/private key pair from an external source for authenticating with the runtime. Using this option implicitly enables plugin authentication prior to registration. Also add a new environment variable to read keys from files. Together with bind-mounted secrets, this should provide enough plumbing to enable transparent authentication of containerized plugins. Signed-off-by: Krisztian Litkey <[email protected]>
Add support for plugin authentication. Authenticating a plugin associates it with a role. A role has a unique name and it can have an optional set of associated tags. These tags are opaque, carrying no semantic meaning for authentication or NRI itself. However, tags can have associated semantics during validation and authorize plugins to perform otherwise restricted actions. This is the primary intended usage for tags: allow validators to associate rights with tags instead of role names. Signed-off-by: Krisztian Litkey <[email protected]>
Implement role based overrides for authenticated plugins. This allows setting a restrictive default configuration and override it with more liberal configuration for some plugins/roles. Signed-off-by: Krisztian Litkey <[email protected]>
Update documentation for plugin authentication and validation. Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
8fe3f62
to
7739284
Compare
This PR implements plugin authentication. The sole purpose of authenticated plugins is to allow finer-grained restrictions of selected NRI features than just a global on/off. This PR also updates the builtin default validator to allow finer-grained restrictions using overrides for authenticated plugins.
In particular the patch series
Here are working trees of updated runtimes with support for authenticated NRI plugins and finer-grained validation using an NRI tree with this PR: