Pular para o conteúdo principal

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

  1. 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"}
    )
  2. Access secrets within your function code. The secrets dictionary is passed as an argument to the handle() 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
    ...
cuidado
  • 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's secrets 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.

cuidado

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?
cuidado

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.

dica

Use Cognite Toolkit to configure, deploy, and manage your Cognite Functions.