This documentation and the Cisco Observability Platform functionalities it describes are subject to change. Data saved on the platform may disappear and APIs may change without notice.

Accessing Platform Services from a Function

A function (in other words, the Docker image that Solution Services loads in response to the function's zodiac:function definition) can access:

  • All the environment variables declared in its envvars attribute.
  • Any platform service that it has permission to access.

Permissions

In order for a solution's functions to access platform services or other functions, the solution must add a iam:SolutionPermissions configuration to their manifest. This is required even for function-to-function calls. The iam:SolutionPermissions configuration defines the permissions for accessing resources from the platform or from other solutions.

URLs

Functions can access platform services at URLs of the format http://${APPD_INTERNAL_EGRESS_HOST}/{route-to-the-api}, where APPD_INTERNAL_EGRESS_HOST is an environment variable that the platform provides to all functions at runtime. If the HTTP request originates from an external call (as opposed to a cron-initiated call, for example), solutions must copy the Authorization header to the new request.

How solution functions make calls into the platform:

  1. For all operations happening in the context of a user, solutions must copy the Authorization header in the request to all of the outgoing requests in the context of the incoming request. If the request does not have an Authorization header and layer-* headers are also not present, the request is denied. Do not set any appd-* headers; the platform either ignores or overwrites them.
  2. (Optional) Solutions set layer-type and layer-id headers to signal what data layer they want to access. If these are not provided, layer-type defaults to "TENANT" and layer-id defaults to the tenantId in the token.