It is important for Foundry users to protect their tokens, API keys, and other authentication material. If tokens are spilled externally (unintentionally exposed) or are compromised by a malicious actor, an unauthorized third-party may be able to access Foundry under the user context of the compromised token.
Foundry uses several different types of tokens:
A user-generated token (or personal access token) is an API key that grants user-level access to all applications in the platform. Users may specify a time-to-live (TTL) for a token on creation. The TTL is the maximum time that the access token will be valid for use. Once the TTL expires, the token is revoked.
One security property of user-generated tokens is that they are unable to generate other user-generated tokens. Only a session token can be used to create a new user-generated token. Learn how to generate this kind of token.
A session token is an ephemeral, time-bound token stored in your browser as a cookie (PALANTIR_TOKEN). When a session token is generated, the token is automatically assigned a time-to-live (TTL). The default TTL is 16 hours. Once the TTL expires, the token is revoked.
A data connector coordinator token is used to authenticate a data connector agent with a Foundry installation. By default, this token is stored in {BOOTVISOR_DIRECTORY}/var/data/coordinator-token.json. The data connector coordinator token grants agent-specific access to the platform.
When a new data connector is created, a time-bound token is dynamically inserted into the deployment tarball. This tarball should be treated as sensitive as it contains authentication material within it.
If a data connector agent is configured with credentials to other data sources (such as a SQL database), additional credential material may be cached or stored locally within the agent.
To prevent your tokens and API keys from being compromised or abused, we recommend the following best practices and behaviors:
A token is “spilled” if the token is exposed or made accessible on an unauthorized system, such as being accidentally published to a publicly-available repository. Any spill of a token should be treated as an information security incident. You should take immediate action to disable the token, and then notify your information security team of the issue. Steps for disabling different types of tokens are available below.
You can revoke user-generated tokens in the Foundry user interface. Learn how in the user-generated token documentation.
To revoke a session token, simply log out of the Foundry instance.
Palantir’s Information Security team runs an automated service that will attempt to identify and revoke spilled tokens in source control on Github.com ↗. If a token is leaked into a public repository on GitHub, the GitHub token revocation service will be notified and will automatically attempt to revoke the token on your behalf.
The GitHub token revocation service is unable to notify you if this revocation occurs. Additionally, if your Foundry installation is not network-accessible from the service, the service will be unable to automatically revoke the token for you.