[WIP] OCPBUGS-65621: add dedicated service account to crb, cvo and version pod #1266
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRoleBinding | ||
| metadata: | ||
| name: cluster-version-operator | ||
| annotations: | ||
| include.release.openshift.io/self-managed-high-availability: "true" | ||
| subjects: | ||
| - kind: ServiceAccount | ||
| name: cluster-version-operator | ||
| namespace: openshift-cluster-version | ||
| roleRef: | ||
| kind: ClusterRole | ||
| name: cluster-admin | ||
| apiGroup: rbac.authorization.k8s.io | ||
| --- | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRoleBinding | ||
| metadata: | ||
| name: cluster-version-operator-payload | ||
| annotations: | ||
| include.release.openshift.io/self-managed-high-availability: "true" | ||
| subjects: | ||
| - kind: ServiceAccount | ||
| name: update-payload-dedicated-sa | ||
| namespace: openshift-cluster-version | ||
| roleRef: | ||
| kind: ClusterRole | ||
| name: cluster-admin | ||
| apiGroup: rbac.authorization.k8s.io | ||
| --- | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRoleBinding | ||
| metadata: | ||
| name: cluster-version-operator | ||
| annotations: | ||
| kubernetes.io/description: Grant the cluster-version operator permission to perform cluster-admin actions while managing the OpenShift core. | ||
| include.release.openshift.io/self-managed-high-availability: "true" | ||
| roleRef: | ||
| kind: ClusterRole | ||
| name: cluster-admin | ||
| subjects: | ||
| - kind: ServiceAccount | ||
| namespace: openshift-cluster-version | ||
| name: default |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| apiVersion: v1 | ||
| kind: ServiceAccount | ||
| metadata: | ||
| name: cluster-version-operator | ||
| namespace: openshift-cluster-version | ||
| annotations: | ||
| kubernetes.io/description: Dedicated Service Account for the Cluster Version Operator. | ||
| include.release.openshift.io/self-managed-high-availability: "true" | ||
| --- | ||
| apiVersion: v1 | ||
| kind: ServiceAccount | ||
| metadata: | ||
| name: update-payload-dedicated-sa | ||
| namespace: openshift-cluster-version | ||
| annotations: | ||
| kubernetes.io/description: Dedicated Service Account for the Update Payload. | ||
| include.release.openshift.io/self-managed-high-availability: "true" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -232,6 +232,7 @@ func (r *payloadRetriever) fetchUpdatePayloadToDir(ctx context.Context, dir stri | |
| }, | ||
| }, | ||
| Spec: corev1.PodSpec{ | ||
| ServiceAccountName: "update-payload-dedicated-sa", | ||
|
Member
There was a problem hiding this comment.
I think "Don't attach privileges to the default service account in OpenShift namespaces" makes a lot of sense, but I'm less clear on the downsides of Pods using the default service account if that account comes with no privileges. This version Pod does not need any Kube API privileges. In fact, it doesn't need any network communication at all, it's just shoveling bits around between the local container filesystem and a volume-mounted host directory. Can we leave it running in the default service account, or is there a way to request no-service-account-at-all? Maybe that's effectively what
Member
There was a problem hiding this comment. Or maybe this is what you're talking about in this thread, and some layer is using the
Member
There was a problem hiding this comment. Poking around in docs turned up these sections dancing in this space, but I'm still not clear if
Author
There was a problem hiding this comment. @wking sorry for the late response - service accounts need to be attached to a pod, whether we specify one or not. If we specified no service account, the Thanks for letting me know about minimum permissions here. We can create a service account without specifying permissions. This way, we don't elevate permissions but we also don't allow default service account usage. I can see if this is all that is required for this deployment. Thanks for looking into further docs on this topic. We can test without to see if the pod genuinely requires elevated permissions or not. |
||
| ActiveDeadlineSeconds: deadline, | ||
| InitContainers: []corev1.Container{ | ||
| setContainerDefaults(corev1.Container{ | ||
|
|
||
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.
I haven't looked into HyperShift, but I expect we'll need a ServiceAccount in the hosted-Kube-API there too?
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.
I can look further into this and get back to you. :)
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.
They appear to be using their own service account and setup --> https://github.com/openshift/hypershift/blob/main/control-plane-operator/controllers/hostedcontrolplane/v2/assets/cluster-version-operator/deployment.yaml
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.
If I can't get my changes to work it might not be a bad idea to replicate their own setup. Thanks for pointing me in the right direction! :)