Skip to content

Token Expiry updates #459

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.

Sign up for GitHub

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

Open
psanghvi17 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Token Expiry updates #459

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/installation/install_epinio.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -201,6 +201,15 @@ The Public Cloud [installation](other_inst_scenarios/install_epinio_on_public_cl

## Internal Epinio components

### Server Configuration

- **`server.defaultTokenExpiry`**: Controls the default expiry time for auth tokens (e.g. `"30s"`, `"60s"`, `"2m"`). Use this to mitigate clock drift in environments where short-lived tokens may expire before use—for example, in staging workloads or when Kubernetes hosts have time synchronization issues. The value is capped at 5 minutes for security. Default is `"30s"`.

```yaml
server:
defaultTokenExpiry: "60s" # Example: increase to 1 minute for clock drift
```

### Staging Workloads

Epinio uses staging workloads to build container images from source code. As you can imagine, container builds can consume varying amounts of CPU, Memory, and Disk space depending on the application. Because of this, it is important that these staging workloads can not only specify those resource amounts but also specify scheduling constraints so that your running applications can be protected from any buildtime resource consumption. For example, you may configure your staging workloads to schedule to a particular node pool within your Kubernetes cluster that is dedicated to builds.
Expand Down