Service Accounts

Posit Connect supports Kubernetes Service Account assignment for content jobs. Service accounts provide identity for Kubernetes workloads and facilitate fine-grained access control against the Kubernetes API or other external resources.

For example, a Kubernetes configuration can restrict access to a particular S3 bucket by service account. To successfully access this bucket, a content job launched by Connect would require an identity that is configured with permissions to access that S3 bucket. Kubernetes service accounts are the mechanism that provides this type of workflow identity.

Configuration

Global Configuration Options

Posit Connect supports several “global” configuration options which define server-wide service account behavior.

Launcher.KubernetesDefaultServiceAccount defines a “default” service account which is applied to all content jobs. If no service account is explicitly set for a particular piece of content, this value is used in the job submission. Further details on Connect’s service account selection logic are provided below.
Launcher.KubernetesValidateServiceAccounts enables the validation of service accounts against an enumeration of the known service accounts fetched by Connect at startup. Further details on Connect’s knowledge of service accounts are provided below.
Launcher.KubernetesContentServiceAccountSelection allows content-level service accounts to be defined and utilized by Connect. Content-level service accounts, if defined for a particular piece of content, are submitted with the content job instead of any value specified by KubernetesDefaultServiceAccount. Further details on Connect’s service account selection logic are provided below.

Content-Level Configuration Options

Posit Connect supports the configuration of service accounts at the content level. This means that a service account can be set for a particular piece of content which overrides any globally-defined service account.

Connect administrators can set content-level service accounts through the dashboard or the content API.

Connect publishers can view the configured service account for a particular piece of content, but cannot modify it.

Service Account Selection

Posit Connect’s typical order-of-precedence when selecting the service account to submit with a Kubernetes job is:

Content-level service account
Global default service account
Do not submit a service account with the job. Fallback to the namespace default service account on the cluster (likely default)

If a piece of content does not have a content-level service account (set through the dashboard or API), Connect then checks for a global default service account (as defined by the Launcher.KubernetesDefaultServiceAccount configuration option) to attach to the content job. If a global default service account is also not configured, Connect does not submit a service account to Kubernetes and instead relies on the namespace default service account (commonly named default).

Note

Global configuration options can modify this order-of-precedence. For example, Launcher.KubernetesContentServiceAccountSelection disables content-level service accounts. If this flag is disabled, Connect ignores the state of the content-level service account entirely for a piece of content and only checks for the configuration of a global default service account.

Accessing Service Accounts from Connect

At startup, Connect attempts to query Kubernetes through Posit Launcher for its enumeration of valid service accounts.

Note

If Connect is having trouble collecting the service account enumeration at startup, check your server logs for any startup warnings and reference the Troubleshooting section below.

This static list of service accounts is used to:

Validate the Launcher.KubernetesDefaultServiceAccount option (if it is populated).
Populate the list of available service accounts for a particular piece of content in the dashboard.
Validate any modifications to a piece of content’s service account.

Warning

Be aware that Connect only attempts to query Kubernetes for an enumeration of service accounts at startup. This means that it is possible for Connect’s enumeration of service accounts to become stale if the state of the cluster changes while Connect is running. Restart Connect to re-sync its enumeration of service accounts. Additional details on the specific behavior that can arise with Connect’s service account enumeration are provided in the Troubleshooting section.

Service Account Validation

Valid DNS Subdomain

Posit Connect always applies a set of fundamental validations, derived from the Kubernetes documentation, against any user-provided service account configurations.

Kubernetes requires that service account names be valid DNS subdomains. Connect validates that submitted service account names meet the requirements of valid DNS subdomains and will error if these rules are violated.

Existence in the Enumeration of Known Service Accounts

If the server configuration option Launcher.KubernetesValidateServiceAccounts is enabled, Connect will attempt to validate that any user-provided service account can be found in the list of service accounts collected at startup. Any service accounts not found in the enumeration will generate an error.

Note that there are several conditions that must be met for this validation to be successful:

Launcher.KubernetesValidateServiceAccounts must be set to true.
Connect must have RBAC permissions to request the service account enumeration to validate against. See the Troubleshooting section for additional details.
The service account must not have been introduced to the cluster after Connect startup. See the Accessing Service Accounts from Connect section for additional details.

Troubleshooting

Connect warns at startup that it is unable to read the set of service accounts from Kubernetes

This means that Connect does not have the Role-Based Access Control (RBAC) permissions required to read the service account enumeration from the Kubernetes API.
- If you are deploying Connect using the Helm chart, consider upgrading to the current chart release. The correct RBAC permissions have been incorporated into the Helm chart.
- If you are using another approach, the Helm chart’s RBAC template can provide a good starting point for considering how to modify your RBAC definitions.
  
  The relevant rule here is simply allowing the list verb against the serviceaccounts resource:
```
rules: 
  - apiGroups:
    - ""
    resources:
    - "serviceaccounts"
    verbs:
    - "list"
```
- If you are unable to grant the necessary RBAC permissions to Connect, your content can still run using service accounts that exist in Kubernetes. This warning is specifically scoped to Connect’s attempt to enumerate the set of available service accounts on the cluster, and does not impact job submission. Consider running Connect with the Launcher.KubernetesValidateServiceAccounts flag set to false to disable validation.
  
  Note
  
  An RBAC definition without the necessary permissions will limit the dashboard’s ability to present service accounts in the UI. Per-content service account settings will need to take place through the server API.
Connect is failing to validate a service account that is defined on the cluster
- It’s possible that Connect’s enumeration of available service accounts is stale. Verify that the service account exists on Kubernetes, then restart your Connect instance to refresh its enumeration of available service accounts.
The service account I select for my content causes my job to fail
- It’s possible that Connect’s enumeration of available service accounts is stale. Verify that the service account exists on Kubernetes, then restart your Connect instance to refresh its enumeration of available service accounts.