Allow the ServiceAccount to be specified for vertica server pods #521
Conversation
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
|
|
||
| apiVersion: vertica.com/v1beta1 |
There was a problem hiding this comment.
Couldn't we also test that if the sa doesn't exist but the role and rolebinding do then only the sa is created with the specified name?
There was a problem hiding this comment.
The operator cannot find user created role/rolebinding. So, if the sa is deleted the operator will generate that along with new role/rolebindings. I'll expand this test to include that scenario.
| // The name of a serviceAccount to use to run the Vertica pods. If this is | ||
| // omitted or the serviceAccount doesn't exist, the operator will create one | ||
| // along with a Role and RoleBinding. | ||
| ServiceAccountName string `json:"serviceAccountName,omitempty"` |
There was a problem hiding this comment.
Is it worth mentioning that "If this is omitted or the serviceAccount does't exist, the operator will create one with respectively an internal generated name or the specified name, as well as a Role and RoleBinding."
There was a problem hiding this comment.
How about this?
If the service account is not specified or does not exist, the operator will create one, using the specified name if provided, along with a Role and RoleBinding.
This allows the serviceAccount to be specified for the vertica server pods. Now that the operator runs at cluster scope, we have separated the service account used to run the operator with the one to run the vertica server pods. In #514 the operator will generate the service account, along with a role and rolebinding, to use. This takes it one step further and allow the user to create the service account ahead of time.
This allows for better integration where the service account needs to be created ahead of time to setup access (e.g. IAM profile via AWS IRSA).
The vertica server pod needs to have read access to k8s secrets in order to read certs. So, a role and rolebinding must be attached to the service account.
One way that someone could use this:
kubectl create serviceaccount vertica-server-sakubectl create -f config/rbac/vertica-server-role.yaml # This will be available as a release artifact tookubectl create rolebinding vertica-server-rolebinding --role vertica-server-role --serviceaccount=<namespace>:<serviceAccountName>spec.serviceAccountNamefield with the name of the service account (e.g. vertica-server-sa)Note, if the service account name is specified, then we assume the necessary role and rolebindings are setup too. The operator will only generate those if it generates the service account also.