Agent authentication

Chef 360 Platform agents authenticate and validate communication to Chef 360 Platform servers using RFC 9421 - HTTP Message Signatures. RFC 9421 - HTTP Message Signatures provides a standardized way to ensure and verify the integrity and authenticity of HTTP messages.

Chef 360 Platform uses HTTP Message Signatures to provide:

• Enhanced API Security: In a client-server architecture, clients often need to authenticate themselves to the server and ensure that their requests haven’t been tampered with. HTTP Message Signatures are used as a method of authenticating Application Programming Interface (API) requests, providing a way for the server to verify that the request comes from a legitimate source and hasn’t been altered.

• Non-Repudiation: Digital signatures ensure that the sender can’t deny sending the message because the signature is unique to the sender and the specific message.

• Mitigating Man-in-the-Middle Attacks: Even with HTTPS, there is a risk of Man-In-The-Middle (MITM) attacks, where an attacker intercepts and alters the communication between the client and the server. HTTP Message Signatures can help to mitigate this risk by ensuring that the message received is exactly what the sender sent.

When combined with HTTPS, RFC 9421 provides a standards-based method to enhance the security of HTTP communications, ensuring the authenticity and integrity of every message. To extend this further Chef 360 Platform uses “mutual” or “two-way” message signing where both the request and response are signed using RFC 9421 HTTP Message Signatures. This ensures that both the client and server can verify the authenticity and integrity of the messages they receive, providing a higher level of security for communication.

When a client node is registered with a server, Chef 360 Platform generates two sets of asymmetric keys. The first set of keys (public and private) represents the client signature, the second set represents the server signature. The server maintains a copy of its private key and the public key for the client. The client, in contrast, maintains a copy of its private key and public key for the server.

Node role link

When an agent is registered, a node role link is created. This means that the given cryptographic keys are bound to a tenant, organization, and role. Any attempt by the agent’s credentials to access data from another tenant or organization results in an invalid message signature.

In addition, as the node role link is also associated with a role, every node is subject to the same Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) rules as users. This ensures that agents follow the Principle of Least Privilege (PoLP). This principle dictates that a user or system should have the minimum level of access (or privileges) needed to perform its tasks. This minimizes the potential impact of a security breach by limiting access to only what’s necessary, reducing the attack surface.