I’m currently working on a project that uses the cloud-relay block within a Raspberry Pi 5, and a deployed AWS lambda, similar to that shown here: AWS Provision Lambda Example
I’ve tested this and it all seems to be working as designed. In the example however, there’s no security associated with the API, so anyone could hit this and provision, and more importantly delete Balena devices in the fleet.
I’m unclear how I can add a layer of security in API Gateway that still allows devices to provision themselves, but additionally blocks all other attempts at access to this API? What does Balena recommend in this instance?
Great to hear that you are successfully using the cloud-relay block and the AWS provisioning Lambda function.
Let me ask internally to try to provide you more guidance about adding a layer of security there. Having said that, feel free to share any ideas that you might have and create a PR in the repo.
In the example however, there’s no security associated with the API, so anyone could hit this and provision, and more importantly delete Balena devices in the fleet.
Add device – First it verifies the provided UUID in balenaCloud, so the client can’t just make up a UUID. Then it verifies that the AWS Thing does not already exist. That combination looks pretty secure.
Delete device – Again the Lambda first verifies the UUID. However, there is no further verification. I agree that we could add some further qualification here. One possibility is to pass the certificate from the device (AWS_CERT variable) and require that it matches the AWS Thing’s copy.
As an administrative action, another possibility is to limit the source for a DELETE request to a certain domain. I don’t know the AWS specifics here though.
You’re right on the adding a device front. The Balena UUID lookup/ AWS thing verification looks reasonable. I know users can still bypass this and create a thing in AWS using the test uuid, but obviously the scope of this is very limited and the test code could simply be removed.
On deleting, I think checking the UUID is a good first step, but these aren’t secrets and could be accessible to someone malicious. Yep passing/ verifying the cert. seems like one good way of managing it. For my use-case I might consider removing the delete path, and only allowing users to do this when properly authenticated into their device management service. Unless there’s an explicit need for the device to need to able to delete it’s self?
In terms of example updates, maybe the cert. validation you suggested on the DELETE path would be a welcome addition? We could add services like AWS WAF into the mix, but that’s maybe beyond the scope of a simple example.
Good to hear we are aligned, @mikey. I don’t see a need for the device to delete its AWS presence. I would rather let an administrator manage that process.
Yes, we’d be happy to review addition of the cert validation to the delete. I agree that this work is intended to be a simple example.