Access Management
How to configure authentication and authorization on your Bacalhau node.
Access Management
Bacalhau includes a flexible auth system that supports multiple methods of auth that are appropriate for different deployment environments.
By default
With no specific authentication configuration supplied, Bacalhau runs in "anonymous mode" – which allows unidentified users limited control over the system. "Anonymous mode" is only appropriate for testing or evaluation setups.
In anonymous mode, Bacalhau will allow:
Users identified by a self-generated private key to submit any job and cancel their own jobs.
Users not identified by any key to access other read-only endpoints, such as to read job lists, describe jobs, and query node or agent information.
Restricting anonymous access
Bacalhau auth is controlled by policies. Configuring the auth system is done by supplying a different policy file.
Restricting API access to only users that have authenticated requires specifying a new authorization policy. You can download a policy that restricts anonymous access and install it by using:
Once the node is restarted, accessing the node APIs will require the user to be authenticated, but by default will still allow users with a self-generated key to authenticate themselves.
Restricting the list of keys that can authenticate to only a known set requires specifying a new authentication policy. You can download a policy that restricts key-based access and install it by using:
Then, modify the allowed_clients variable in challange_ns_no_anon.rego to include acceptable client IDs, found by running bacalhau agent node.
Once the node is restarted, only keys in the allowed list will be able to access any API.
Username and password access
Users can authenticate using a username and password instead of specifying a private key for access. Again, this requires installation of an appropriate policy on the server.
Passwords are not stored in plaintext and are salted. The downloaded policy expects password hashes and salts generated by scrypt. To generate a salted password, the helper script in pkg/authn/ask/gen_password can be used:
This will ask for a password and generate a salt and hash to authenticate with it. Add the encoded username, salt and hash into the ask_ns_password.rego.
Writing custom policies
In principle, Bacalhau can implement any auth scheme that can be described in a structured way by a policy file.
Custom authentication policies
Bacalhau will pass information pertinent to the current request into every authentication policy query as a field on the input variable. The exact information depends on the type of authentication used.
challenge authentication
challenge authenticationchallenge authentication uses identifies the user by the presence of a private key. The user is asked to sign an input phrase to prove they have the key they are identifying with.
Policies used for challenge authentication do not need to actually implement the challenge verification logic as this is handled by the core code. Instead, they will only be invoked if this verification passes.
Policies for this type will need to implement these rules:
bacalhau.authn.token: if the user should be authenticated, an access token they should use in subsequent requests. If the user should not be authenticated, should be undefined.
They should expect as fields on the input variable:
clientId: an ID derived from the user's private key that identifies them uniquelynodeId: the ID of the requester node that this user is authenticating withsigningKey: the private key (as a JWK) that should be used to sign any access tokens to be returned
The simplest possible policy might therefore be this policy that returns the same opaque token for all users:
ask authentication
ask authenticationask authentication uses credentials supplied manually by the user as identification. For example, an ask policy could require a username and password as input and check these against a known list. ask policies do all the verification of the supplied credentials.
Policies for this type will need to implement these rules:
bacalhau.authn.token: if the user should be authenticated, an access token they should use in subsequent requests. If the user should not be authenticated, should be undefined.bacalhau.authn.schema: a static JSON schema that should be used to collect information about the user. Thetypeof declared fields may be used to pick the input method, and if a field is marked aswriteOnlythen it will be collected in a secure way (e.g. not shown on screen). Theschemarule does not receive anyinputdata.
They should expect as fields on the input variable:
ask: a map of field names from the JSON schema to strings supplied by the user. The policy should validate these credentials.nodeId: the ID of the requester node that this user is authenticating withsigningKey: the private key (as a JWK) that should be used to sign any access tokens to be returned
The simplest possible policy might therefore be one that asks for no data and returns the same opaque token for every user:
Custom authorization policies
Authorization policies do not vary depending on the type of authentication used – Bacalhau uses one authz policy for all API requests.
Authz policies are invoked for every API request. Authz policies should check the validity of any supplied access tokens and issue an authz decision for the requested API endpoint. It is not required that authz policies enforce that an access token is present – they may choose to grant access to unauthorized users.
Policies will need to implement these rules:
bacalhau.authz.token_valid: true if the access token in the request is "valid" (but does not necessarily grant access for this request), or false if it is invalid for every request (e.g. because it has expired) and should be discarded.bacalhau.authz.allow: true if the user should be permitted to carry out the input request, false otherwise.
They should expect as fields on the input variable for both rules:
http: details of the user's HTTP request:host: the hostname used in the HTTP requestmethod: the HTTP method (e.g.GET,POST)path: the path requested, as an array of path components without slashesquery: a map of URL query parameters to their valuesheaders: a map of HTTP header names to arrays representing their valuesbody: a blob of any content submitted as the body
constraints: details about the receiving node that should be used to validate any supplied tokens:cert: keys that the input token should have been signed withiss: the name of a node that this node will recognize as the issuer of any signed tokensaud: the name of this node that is receiving the request
Notably, the constraints data is appropriate to be passed directly to the Rego io.jwt.decode_verify method which will validate the access token as a JWT against the given constraints.
The simplest possible authz policy might be this one that allows all users to access all endpoints:
Last updated
Was this helpful?