Protecting tokens and API keys（保护令牌和API密钥）¶
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.
Tokens¶
Foundry uses several different types of tokens:
User-generated 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.
Session 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.
Data connector coordinator token¶
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.
Best practices for tokens¶
To prevent your tokens and API keys from being compromised or abused, we recommend the following best practices and behaviors:
- Never give tokens to another user or post tokens publicly.
- Ideally use environment variables when locally working with tokens.
- If you choose to use dotfiles for token storage, ensure that the dotfiles are excluded from version control.
- Do not put tokens into command line arguments.
- Do not hardcode tokens in scripts or software.
- Revoke unused or unnecessary tokens.
- Apply reasonable time-to-live values for user-generated tokens.
- Do not use browser-based cookie synchronization technologies for other devices.
- Minimize the number of browser extensions you use.
Token spills¶
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.
Revoke user-generated tokens¶
You can revoke user-generated tokens in the Foundry user interface. Learn how in the user-generated token documentation.
Revoke session tokens¶
To revoke a session token, simply log out of the Foundry instance.
GitHub token revocation service¶
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.
中文翻译¶
保护令牌和API密钥¶
对于Foundry用户而言，保护其令牌、API密钥及其他认证材料至关重要。如果令牌意外泄露或被恶意行为者窃取，未经授权的第三方可能利用被泄露的令牌在用户上下文中访问Foundry。
令牌(Token)¶
Foundry使用以下几种不同类型的令牌：
用户生成的令牌(User-generated token)¶
用户生成的令牌（即个人访问令牌）是一种API密钥，可授予用户级别访问平台所有应用的权限。用户在创建令牌时可以指定生存时间(TTL)。TTL是访问令牌保持有效的最大时长。一旦TTL到期，令牌即被撤销。
用户生成令牌的一个安全特性是，它们无法生成其他用户生成的令牌。只有会话令牌才能用于创建新的用户生成令牌。了解如何生成此类令牌。
会话令牌(Session token)¶
会话令牌是一种临时性的、有时限的令牌，以Cookie(PALANTIR_TOKEN)形式存储在浏览器中。生成会话令牌时，系统会自动为其分配生存时间(TTL)。默认TTL为16小时。一旦TTL到期，令牌即被撤销。
数据连接器协调器令牌(Data connector coordinator token)¶
数据连接器协调器令牌用于将数据连接器代理与Foundry安装实例进行身份验证。默认情况下，此令牌存储在{BOOTVISOR_DIRECTORY}/var/data/coordinator-token.json中。数据连接器协调器令牌授予代理特定级别的平台访问权限。
创建新的数据连接器时，系统会动态地将一个有时限的令牌插入到部署压缩包中。该压缩包应被视为敏感文件，因其包含认证材料。
如果数据连接器代理配置了其他数据源（如SQL数据库）的凭据，额外的凭据材料可能会被缓存或本地存储在代理中。
令牌最佳实践¶
为防止令牌和API密钥被泄露或滥用，我们建议遵循以下最佳实践和行为准则：
- 切勿将令牌交给其他用户或在公开场合发布令牌。
- 在本地使用令牌时，最好使用环境变量。
- 如果选择使用点文件(dotfile)存储令牌，请确保将这些点文件排除在版本控制之外。
- 不要将令牌放入命令行参数中。
- 不要在脚本或软件中硬编码令牌。
- 撤销未使用或不必要的令牌。
- 为用户生成的令牌设置合理的生存时间值。
- 不要使用基于浏览器的Cookie同步技术同步到其他设备。
- 尽量减少使用的浏览器扩展程序数量。
令牌泄露(Token spills)¶
如果令牌在未经授权的系统上被暴露或可被访问，例如意外发布到公开可用的代码仓库中，则视为令牌"泄露"。任何令牌泄露都应被视为信息安全事件。您应立即采取措施禁用该令牌，然后通知您的信息安全团队。以下是禁用不同类型令牌的步骤。
撤销用户生成的令牌¶
您可以在Foundry用户界面中撤销用户生成的令牌。请参阅用户生成的令牌文档了解具体操作方法。
撤销会话令牌¶
要撤销会话令牌，只需退出Foundry实例即可。
GitHub令牌撤销服务¶
Palantir的信息安全团队运行一项自动化服务，该服务会尝试识别并撤销Github.com ↗源代码控制中泄露的令牌。如果令牌泄露到GitHub上的公共仓库中，GitHub令牌撤销服务将收到通知，并自动尝试代表您撤销该令牌。
如果发生此撤销操作，GitHub令牌撤销服务无法通知您。此外，如果您的Foundry安装实例无法从该服务进行网络访问，则该服务将无法自动为您撤销令牌。