Serverless

The serverless feature allows workloads without access to a SPIFFE Unix Domain Socket to receive SVIDs and bundles. Instead of using an agent to identify the workload by introspecting the underlying platform, the workload provides their own proofs.

When to use

This feature is specifically designed for environments where it's not possible, or undesirable, to offer a standard SPIFFE Unix Domain Socket with the SPIFFE Workload API to workloads.

This can be due to:

• No access to the underlying operating system.
• Restrictions on using hostPath in Kubernetes.
• Serverless functions such as AWS Lambdas, GCP Cloud Run or Azure Functions.
• Any other restrictions that make the SPIFFE Workload API over UDS undesirable or impossible.

How it works

When serverless is enabled on a trust domain a new API becomes available on the Trust Domain Server that can be used directly by workloads. This API allows workloads to supply proofs such as Instance Metadata Documents or platform tokens. The server validates those proofs and issues SVIDs to the workload when all conditions are met. This process is called Remote Attestation.

Attestation Policies

To configure what environments and workloads are allowed to receive SVIDs using remote attestation you define Serverless Attestation policies. Every policy describes a certain environment and enforces attestation methods on it. Example attestation methods include Azure Managed Identity or a GCP Service Account.

For a workload to receive an SVID using Remote Attestation it needs to fulfill all the requirements of any policy. Otherwise, the request is denied.

Here is an example of an Attestation Policy that allows GCP Service Accounts in the my-gcp-project-id project ID to receive individual SVIDs where the SPIFFE ID is composed of the project ID and service account ID.

section: ServerlessAttestation
schema: v1
spec:
  policies:
    - name: gcp-sandbox
      svidPolicy:
        pathTemplate: "/gcp/{{gcp_iit.project_id}}/{{gcp_iit.service_account.id}}"
      requiredAttestors:
        - type: gcp_iit
          config:
            allowNonComputeTokens: true
            allowedProjectIDs:
              - "my-gcp-project-id"

Assuming your trust domain is example.org and your Service Account ID is sales-api the resulting SVID of above configuration would be spiffe://example.org/gcp/my-gcp-project-id/sales-api.

Available Methods

Method	Type identifier	Attributes produced	Common use case
AWS Web Identity Token	aws_token	Account, org, IAM tags	AWS workloads with IAM outbound federation
Azure MSI	azure_msi	Tenant ID, principal ID	Azure VMs with Managed Identity
GCP Instance Identity Token	gcp_iit	Project, instance, zone, labels	GCP Compute Engine VMs

Attributes available for SVID issuance

Attestation methods produce attributes derived from the workload's attested identity. These attributes are available for use in:

• SPIFFE ID path templates
• X.509-SVID customization templates
• JWT-SVID additional claims

Considerations

Scale & Resiliency

Serverless has scale and resiliency limitations that are important to take into consideration. Requests on the serverless API are directly being processed by the Trust Domain Server and are less likely to have cache hits compared to the traditional agent-based approach, where some processing is performed by the agent and may result in cached results. It is also not covered by the Downtime Protection feature.

You can mitigate certain aspects of it by deploying a dedicated Trust Domain Server for serverless use cases. This creates a dedicated availability group and the traditional agent-based availability remains unaffected.

Reachability

By its nature, the serverless API on the Trust Domain Server must be reachable over TCP. This contrasts with the SPIFFE Workload API, which is served over a Unix Domain Socket and is typically not reachable over the network.

Generally speaking it is advisable to enforce network policies and allow only the specific environments of workloads to access the serverless API.

Security

The security of serverless is strongly tied to the policies that govern the serverless issuance. Strong policies restrict issuance to only the workloads that are meant to receive SVIDs. Weak policies can allow arbitrary workloads to access the API and receive SVIDs, including workloads or actors outside of your environment.

Recommendations:

• Enforce strong network policies on the endpoint serving the serverless API at the Trust Domain Server.
• Write policies scoped to the serverless workload environment as fine-grained as possible.
• Enforce strong access control over the management of serverless attestation policies.

Contact Defakto Support to assist with any security reviews of your serverless deployment.