-
Notifications
You must be signed in to change notification settings - Fork 62
✨ auth: use synthetic user/group when service account is not defined #1816
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?
✨ auth: use synthetic user/group when service account is not defined #1816
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
dfc5ccb
to
fbcc4a5
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1816 +/- ##
==========================================
+ Coverage 66.82% 66.93% +0.10%
==========================================
Files 75 76 +1
Lines 6337 6378 +41
==========================================
+ Hits 4235 4269 +34
- Misses 1839 1844 +5
- Partials 263 265 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
11210fc
to
e44c4d2
Compare
I'd like to have a discussion on the |
1c2f38f
to
73e6080
Compare
I put next to no critical thought into the name and group names. @thetechnick you propose the following?
|
73e6080
to
fb13084
Compare
@joelanford precisely. 👍 |
59b818a
to
c9575d3
Compare
hack/demo/resources/synthetic-user-perms/argocd-clusterextension.yaml
Outdated
Show resolved
Hide resolved
c9575d3
to
76ca00e
Compare
cd6d528
to
7546680
Compare
} | ||
} | ||
|
||
func ClusterExtensionUserRestConfigMapper(tokenGetter *authentication.TokenGetter) func(ctx context.Context, o client.Object, c *rest.Config) (*rest.Config, error) { |
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.
Should we pass a enableSyntheticUserAuthentication
function parameter so that we can reference the feature gate only in main.go
?
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.
is that a general goal that we have that FGs should only be referenced in main? I might need to update the Single-OwnNamespace FG if that's the case. My only worry about it is that if it's only checked somewhere down the stack, we end up having to thread it all the way down, which could be painful. What is the value of having it in main? In the end I end up searching the code for usages of the FG anyway. Is it helpful in other contexts as well?
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.
My main thinking for this was to avoid functionality controlled by global state, which generally causes pain and can turn things into spaghetti if we aren't careful.
If we want to library-ify some of this underlying functionality, where/how to we envision the feature gates being implemented and setup? I guess I view the feature gates as attributes of the main binary, not of the libraries that the main binary uses.
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.
then maybe the right way is to separate the implementations entirely and switch implementations depending on the FG. I'll try that.
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.
Fixed ^^ not quite! forgot to tidy up
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.
ok - now it's good =D
48cb945
to
9904073
Compare
9904073
to
7c61178
Compare
7c61178
to
02255cd
Compare
cmd/operator-controller/main.go
Outdated
@@ -304,7 +304,7 @@ func run() error { | |||
return err | |||
} | |||
tokenGetter := authentication.NewTokenGetter(coreClient, authentication.WithExpirationDuration(1*time.Hour)) | |||
clientRestConfigMapper := action.ServiceAccountRestConfigMapper(tokenGetter) | |||
clientRestConfigMapper := action.ClusterExtensionUserRestConfigMapper(tokenGetter) |
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.
We use the SA to generate the names at: https://github.com/operator-framework/operator-controller/blob/main/internal/operator-controller/rukpak/render/generators/generators.go#L84
How would that be after this change?
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.
That SA is the name of an SA that is provided in the permissions section of the CSV. This SA is the SA in the ClusterExtension spec.
Different SAs :)
8dec944
to
fcc4a15
Compare
Signed-off-by: Joe Lanford <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
Signed-off-by: Per Goncalves da Silva <[email protected]>
fcc4a15
to
626ba75
Compare
# enable synthetic-user feature gate | ||
- op: add | ||
path: /spec/template/spec/containers/0/args/- | ||
value: "--feature-gates=SyntheticPermissions=true" |
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.
👍 Cool
kubectl apply -f ${DEMO_RESOURCE_DIR}/synthetic-user-perms/argocd-clusterextension.yaml | ||
|
||
# wait for cluster extension installation to succeed | ||
kubectl wait --for=condition=Installed clusterextension/argocd-operator --timeout="60s" |
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.
WDYT about we add something like
# List ClusterRoleBindings for the synthetic group
kubectl get clusterrolebindings -o json | jq -r '
.items[] |
select(.subjects[]? | .kind == "Group" and .name == "olm:clusterextensions") |
"\(.metadata.name) → \(.roleRef.kind)/\(.roleRef.name)"
'
# List RoleBindings for the synthetic user
kubectl get rolebindings --all-namespaces -o json | jq -r '
.items[] |
select(.subjects[]? | .kind == "User" and .name == "olm:clusterextensions:argocd-operator") |
"\(.metadata.namespace)/\(.metadata.name) → \(.roleRef.kind)/\(.roleRef.name)"
'
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.
Maybe would be nice add in the demo:
Have we here any step we could add in the demo to prove and show that with the synthetic-user-permissions the workload will have the required permission to run BUT the logged user will not able to take advantage of it to scalate the permissions?
However, it might not too be too simple. So, I am fine without it.
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.
Just a few nits. ( not mandatory )
It is protected behind a feature gate, so 👍
/lgtm
/approve
I could not find any reason for not move forward with protected as it is.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Today at a meeting among maintainers of OLMv1, we discussed an idea that @thetechnick proposed awhile back. That is: stop using service accounts and service account tokens. Instead use synthetic names with impersonation.
While we are now 1.0.0 with support for service accounts, we can deprecate that feature and recommend attaching permissions to synthetic users/groups instead.
This PR demonstrates how we might do this. But with the API change, we should write up a detailed design and gain consensus.
This PR uses:
"olm:clusterextensions:<clusterExtensionName>"
["olm:clusterextensions", "system:authenticated"]
(not sure we need to be explicit aboutsystem:authenticated
, but it can't hurt)Reviewer Checklist