Permissions - Self-hosted
Permissions and setup required for deploying Briefer’s enterprise version on Kubernetes.
Briefer’s enterprise version requires specific permissions to function correctly on your Kubernetes cluster.
This page outlines everything you need to set up before deploying the application.
There are four main areas where permissions are required:
- Kubernetes: to install and run the Briefer application
- AWS ECR/IAM (IRSA): to pull enterprise images from Briefer’s private ECR
- AWS Bedrock: to invoke foundation models for AI features
- RDS (optional): to connect to an external database (an RDS instance) for storing Briefer’s data
Each of these is described in detail below.
1. Permissions for installing the Helm chart
You will need to ensure that you can install Helm charts on your Kubernetes cluster. This is a requirement for installing Briefer.
When installing Briefer’s helm chart, you will need to ensure that you can grant the following permissions within the desired namespace:
Briefer uses this permissions to manage Jupyter runtimes and other components of the application, including secrets with environment variables for your Jupyter environments.
2. AWS Permissions to Pull Images from Briefer’s ECR
Create an IAM role in your AWS account with the policy below. Make sure to replace that placeholder with the actual role name we will provide you.
In addition to these role permissions, make sure this role also has a Trust Relationship policy that allows the Kubernetes service account to assume it.
Below, you can see an example of a Trust Relationship policy using IRSA (IAM Roles for Service Accounts) to allow the briefer-pull
Kubernetes service account to assume the role. Make sure to replace the placeholders with the actual values for your AWS account and EKS cluster.
This permission allows the CronJob to assume a cross-account role in our AWS account and pull enterprise container images from our private ECR.
Briefer deploys a Kubernetes CronJob that keeps your image pull secret up to date. This CronJob uses IRSA (IAM Roles for Service Accounts) to authenticate with AWS.
Once the role is properly configured, the CronJob will handle authentication and secret updates automatically — no manual image pulls required.
3. AWS Permissions to Invoke Bedrock Models
To enable Briefer’s AI capabilities, your deployment role must have permission to invoke specific foundation models on AWS Bedrock.
First, make sure that you enable the desired models (Claude 3.5, Claude 3.7 and Titan) in your AWS account. You can do this by going to the AWS Bedrock console and enabling the models you want to use, as explained in the AWS docs here.
The following policy grants the required access:
Just like the ECR permissions, make sure this role also has a Trust Relationship policy that allows the Kubernetes service account to assume it.
As an example, here is a Trust Relationship policy using IRSA (IAM Roles for Service Accounts) to allow the briefer-api
service account to assume the role. Make sure to replace the placeholders with the actual values for your AWS account and EKS cluster.
Make sure that you enable the Bedrock service in your AWS account and that you have access to the models you want to use.
4. (Optional) Using a Managed RDS Database
Briefer supports running its internal database either inside the Kubernetes cluster or via an external RDS instance. We strongly recommend using RDS for production setups due to its improved reliability and performance.
To use RDS:
- Provision a PostgreSQL instance in your AWS account
- Create a database
- Create a user with read/write permissions
- Save the connection string and credentials
You will later provide these values in Briefer’s Helm chart configuration.
We also recommend configuring periodic backups and snapshots for your RDS instance to ensure data durability.
Briefer does not require permissions to create or manage RDS resources directly - but someone in your organization must provision the database before deployment if you want to use RDS.