Securing Cognite Functions
Cognite Functions extends the capabilities of Cognite Data Fusion (CDF) and enables you to run custom code within the platform. Follow these best practices to ensure the security and integrity of your data.
How to handle secrets
Use the dedicated secrets
field to manage security credentials, passwords, and certificates. The information in this field is encrypted and stored with per-function encryption, separately from the code for your function.
Best practices
- Define secrets when you create the function. Use the dedicated
secrets
dictionary argument during creation.# Secrets are defined securely during function creation
client.functions.create(
name="my-secure-function",
...
secrets={"API_KEY": "your-secret-key"}
) - Access secrets within your function code. The
secrets
dictionary is passed as an argument to thehandle()
method, allowing you to access them securely at runtime.# Inside your function's handle method
def handle(client, data, secrets):
# The 'secrets' dict is passed directly as an argument
api_key = secrets.get("API_KEY")
# Now you can use the api_key safely
...
-
Do not hard-code secrets directly in your function's source code. They'll be visible to anyone with permission to read the corresponding source code file in the Files API.
-
While data passed through the
data
field is encrypted in motion, the function'ssecrets
are encrypted at rest and in motion with a per-function-key and persist for the lifecycle of the function.
Don't expose secrets in logs
Be cautious with the information you print or log from within your Cognite Function. Anyone with functions:read
access in your CDF project can view the logs. Accidentally printing a secret can expose it to a wider audience than intended.
Never print or return sensitive data from your function's handle()
method. If you require output for debugging, use non-sensitive placeholder values. In general, make sure secrets and tokens can't leak through logs or API requests other than what is intended.
Secure your dependencies
Your function is Python code built into a container. All standard software supply chain risks apply. Consider pinning packages to known-good versions. Some organizations may want to control updates to the requirements.txt
files, or even use a private package repository. To use a private package repository with index_url
, read about the intrinsic security implications.
Only run trusted functions
When you call a Cognite Function, it runs with the permissions of the session provided. This can be a service account, or it can be a user's own permissions at the time they invoke a function through the CDF user interface. If the account has broad permissions, such as admin access, the function could perform any action these permissions allow. Following the principle of least privilege, invoke functions with the smallest set of permissions needed to perform the task of the function.
Functions can access the public internet to connect with external services. Make sure your functions handle data appropriately and communicate only with authorized systems.
Before invoking a function in the CDF user interface, consider:
- Do I trust the author and source of this function?
- Do I have a clear understanding of the actions this function will perform?
- Am I comfortable with this function executing with my level of access?
Only invoke functions from trusted sources that you have reviewed and fully understand. This practice helps prevent unintended or malicious actions within your CDF project.
Deploy functions with CI/CD and Cognite Toolkit
Similar to other services and applications, commit the source code of your functions to a repository, for example, GitHub, with peer reviews and Continuous Integration/Continuous Deployment.
Use Cognite Toolkit to configure, deploy, and manage your Cognite Functions.