Reduce System Account Coupling #260
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
See what you make of this... sister pulls exist in nscaledev/uni-kubernetes#244 and nscaledev/uni-compute#62 |
We define a single system account role that is used by (at present) the Kubernetes and Compute services. This has a few drawbacks: first you have to modify identity to enable new functionality in either of those services, and secondly you may inadvertently give away permissions that aren't strictly necessary. What this does is allows each service to define a SystemAccount resource in their own Helm chart, linked to their own role. It also means 3rd party services can define all their own stuff in situ without having to tell the Identity service about itself, or know where the Identity service lives in order to install custom roles. Security wise, anyone who can create a certificate, role and system account can then issue a token to do what they want, so I guess limiting who can do those operations brings security, or perhaps having a PSK to validate the resource is trusted via the PSK. Prior to this a user would have to issue a certificate, create a role (or just reference the uber user one - perhaps we should grant this implicitly via a magical *.* ACL) and modify the identity deployment. So perhaps backward a little bit, but it does offer operational and development benefits.
spjmurray
force-pushed
the
system_accounts
branch
from
0770a47 to
d685120
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We define a single system account role that is used by (at present) the Kubernetes and Compute services. This has a few drawbacks: first you have to modify identity to enable new functionality in either of those services, and secondly you may inadvertently give away permissions that aren't strictly necessary.
What this does is allows each service to define a SystemAccount resource in their own Helm chart, linked to their own role. It also means 3rd party services can define all their own stuff in situ without having to tell the Identity service about itself, or know where the Identity service lives in order to install custom roles.
Security wise, anyone who can create a certificate, role and system account can then issue a token to do what they want, so I guess limiting who can do those operations brings security, or perhaps having a PSK to validate the resource is trusted via the PSK. Prior to this a user would have to issue a certificate, create a role (or just reference the uber user one - perhaps we should grant this implicitly via a magical *.* ACL) and modify the identity deployment. So perhaps backward a little bit, but it does offer operational and development benefits.