Skip to content
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

Operator's Service account placement in versions 1.3.0 #4468

Closed
Avni-Sharma opened this issue Feb 3, 2021 · 2 comments · Fixed by #4626
Closed

Operator's Service account placement in versions 1.3.0 #4468

Avni-Sharma opened this issue Feb 3, 2021 · 2 comments · Fixed by #4626
Assignees
Labels
kind/documentation Categorizes issue or PR as related to documentation. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/support Indicates an issue that is a support question.
Milestone

Comments

@Avni-Sharma
Copy link
Contributor

In versions 0.16.0 and 0.17.0 I had observed that the deploy/ folder had roles, rolebindings, crds, deployment and service account. After migrating to a new version 1.3.0 I can find the crds, roles and rolebindings placed at various folders but however, I am not able to locate the operator's service account.

For making a single release yaml for our operator, we initially used to curate everything present under the deploy/ folder under a single yaml file for a single file installation of the operator.

Currently, I am trying to extract the deployment, roles and crds from the already present bundle image's csv and other data under manifests/. However, the service account resource yaml does not exist. Is there any way wherein I can achieve to create a single release artifact yaml, for quick kubectl create -f installation.yaml of the operator in vanilla k8s

@estroz estroz self-assigned this Feb 4, 2021
@estroz estroz added this to the Backlog milestone Feb 4, 2021
@estroz estroz added the triage/support Indicates an issue that is a support question. label Feb 4, 2021
@estroz
Copy link
Member

estroz commented Feb 4, 2021

The default service account is used for a particular namespace by default. Creating and using a separate service account involves a few steps:

  1. Create service_account.yaml and put it in config/rbac/
  2. Add a service_account.yaml to the list of resources in config/rbac/kustomization.yaml
  3. Change all ServiceAccount-type subjects[].name to the service account name in all RoleBinding/ClusterRoleBinding manifests in config/rbac/
  4. Set the pod template spec's serviceAccountName to the service account name in your config/manager/manager.yaml
  5. Rerun make bundle

This needs to be documented for all operators.

/kind documentation

@openshift-ci-robot openshift-ci-robot added the kind/documentation Categorizes issue or PR as related to documentation. label Feb 4, 2021
@estroz estroz modified the milestones: Backlog, Post 1.0 Docs Feb 4, 2021
@estroz estroz added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Feb 15, 2021
@estroz
Copy link
Member

estroz commented Mar 9, 2021

This is fixed by kubernetes-sigs/kubebuilder#2070 upstream.

@estroz estroz modified the milestones: Post 1.0 Docs, v1.7.0 Mar 9, 2021
@estroz estroz modified the milestones: v1.7.0, v1.5.0 Mar 10, 2021
fantapsody added a commit to streamnative/flink-operator that referenced this issue Aug 20, 2021
Previously the project is using the `default` service account to deploy and run the operator, which is not safe. This PR follows the [introduction](operator-framework/operator-sdk#4468) to run the operator with a project-specific service account (xxx-operator-controller-manager) to fix this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Categorizes issue or PR as related to documentation. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/support Indicates an issue that is a support question.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants