Service accounts
A ServiceAccount is an application-scoped identity on the Controller. The identity is the pair (applicationName, metadata.name). It is not a cluster-wide name.
metadata.applicationName is required. It must match an Application metadata.name. roleRef sits at the document root and names the Role. It is not a field of spec.
Fields are on ServiceAccount fields.
Human Console and API access uses a RoleBinding with a User or Group subject. A binding can also name this account. The subject name on that binding is metadata.name, not application/name.
The microservice sets spec.serviceAccount.roleRef to the Role. See Microservices and the field on Microservice fields.
Deploy Role, then RoleBinding, then ServiceAccount, then the microservice. Inside one file, the CLI sorts kinds in that order. Deploy the Application first when that name is not already on the Controller.
Deploy
potctl deploy -f serviceaccount.yaml -n my-ecn
potctl get serviceaccounts -n my-ecn
potctl describe serviceaccount my-app/worker -n my-ecn
potctl delete serviceaccount my-app/worker -n my-ecn
deploy creates the account when the pair is missing. The same pair replaces roleRef. There is no apply.
describe and delete use APP/NAME. get serviceaccounts lists the application, the name, and the role.
An empty metadata.applicationName is rejected. metadata.namespace is the potctl namespace (-n).
describe serviceaccount prints applicationName on metadata and roleRef at the document root. delete serviceaccount takes APP/NAME.
Example
apiVersion: datasance.com/v3
kind: ServiceAccount
metadata:
name: worker
namespace: my-ecn
applicationName: my-app
roleRef:
kind: Role
name: app-worker
The Role app-worker should already exist. A full Role, binding, and account file is on Access control.
Console
Open Access control, then Service Accounts. See Access control.