Given the framework supports optimistic UI, the server code including api keys and secrets can wind up on client. Should measures be taken when using those within actions?
Actions only run server-side, so you can use API keys and secrets safely there.
Related
Before I conclude that I can't do this with google cloud workflows alone, I just wanted to check with the community that I'm not missing anything...
I have a google cloud workflows program which exports data from BigQuery to GCS and then sends an email to a user with a URL in the body of the email. I want this URL to be signed.
The gcloud CLI and language-specific libraries all come with nice helpers to do this but I can't access any of this direct from google cloud workflows. I considered implementing my own sub-workflow which would perform the logic described in the signing URLS manually documentation but I don't think I can do this from Workflows alone (I could easily create some cloud func which I call [and in that case, I could just use the helper from the python SDK for example] but I'm trying to avoid that). The following functionality from the python example constitute blockers; logic that I believe I can't do from google cloud workflows alone - unless anyone knows of public web services that I can call to get around this?
canonical_request_hash = hashlib.sha256(canonical_request.encode()).hexdigest()
signature = binascii.hexlify(google_credentials.signer.sign(string_to_sign)).decode()
Everything else I could just about do in a fairly long and drawn out sub-workflow... but it would be possible.
Cloud Workflows do not natively support hashing & RSA signing libraries within its Standard library which is a core requirement of GCS URL signing algorithm.
As also advised in public docs, Cloud workflows / sub-workflows should be primarily used as an orchestration flow to invoke services, parse responses, and construct inputs for other connected services. Services (like Cloud Function / Run etc.) should be created to perform any work that is too complex for Workflows or for operations that are not natively supported by Workflows expressions and its standard library.
Solution for above use case is to either:
a) Create a service (~ triggered from Cloud Workflow) like Cloud Function to generate signed GCS URLs.
OR b) Generate the GCS Signed URL as an independent task outside & after execution of the core workflow operation as shown in this sample.
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
We are currently deploying to AppSync using the serverless-appsync plugin and the serverless-framework (naturally).
Our API is 100% public and unauthenticated. All queries and mutations are basically public, since we have at this point no need for users (via a Cognito pool for example).
We have added a first layer of security using api keys but this is undoubtedly not much, as the api key is included as-is in the frontend sources. We would like to add extra roadblocks to make it harder for malicious users to abuse that frontend API.
A few things come to mind:
rate limiting (not currently supported by AppSync but I've read it's apparently in the works). I do not want to do this using a custom made solution in a Lambda for example.
making sure only traffic from the website is allowed to use our API, in addition to our own devs... I could probably do this with pipeline resolvers but I am not too keen with doing that in that obscure and unwieldy VTL language.
cors, ...
I'm considering switching to Apollo Server since this solution seems more open and configurable...
I would recommend using AppSync's IAM auth option and then use Amazon Cognito Identity Pools to vend temporary AWS credentials to your client applications. Identity pools (as opposed to user pools) vend temporary AWS credentials that assume the access of a role of your choosing. When configuring the identity pool, you can define a role with full access to the AppSync API or you may selectively provide access. From the client applications, you use the temporary credentials to sign the requests to AppSync using SigV4 and AppSync will only allow requests with a valid signature to be executed. The temporary credentials also provide an extra layer of security as even if they are compromised, each credential will only provide access up to the max allowed time.
I'll also add that you can use multiple auth modes at once with an AppSync API. This allows you to protect all fields as mentioned above and then selectively mark specific other fields such that they are authorized via some other mechanism like user pools or OIDC.
Starting completely from scratch with a new server. Do we need to specify a filekey? If so, does it has to be something specific when I use AWS storage or not?
In parse-server you dont have to put this keys
this is from parse-server wiki
Parse Server does not require the use of client-side keys. This includes the client key, JavaScript key, .NET key, and REST API key.
The Application ID is sufficient to secure your app.
However, you have the option to specify any of these four keys upon
initialization. Upon doing so, Parse Server will enforce that any
clients passing a key matches. The behavior is consistent with hosted
Parse.
The problem with this keys that they publish with you app and all of them (javascript key file key...) are not private. So their is no security benefit to use them.
I see that rethinkdb now has an app server called horizon and it's examples include a lot of client apps without any backend server code.
If I wanted to create a REST api service with rethinkdb - does horizon still add value or should I just create a standard node.js rest api using rethinkdb libraries directly?
I see that horizon has some authentication, authorization and permissions built in which could be useful but I'm not sure if turning it into an api instead of a standard web app is making horizon bend into something it's not supposed to be.
If I wanted to create a REST api service with rethinkdb - does horizon
still add value
No, if all you want is a REST API endpoint mapping CRUD operations onto your RethinkDB data, then Horizon won't help you there.
Horizon is great if you want websocket API w/ "real-time" features and plan to use the Horizon client in the browser.
Horizon is opinionated in how it handles users and permissions (it enforces them on the server side using different users/permissions for each app instead of the RethinkDB users table).
# RethinkDB
r.db('rethinkdb').table('users')
r.db('rethinkdb').table('permissions')
# Horizon
r.db('myapp_internal').table('users')
r.db('myapp_internal').table('users_auth')
I'm currently playing around with a stack that uses feathers to design common services that can be exposed over a REST or websocket transport. Its more complex, but I might use both feathers and Horizon, but there will be some work to map permissions correctly across both endpoints. (Plus schema enforcement...) Feathers supports various authentication providers that return JWT which you could then pass to horizon (if you set the same secret_key)...
If you don't need the real-time features in your database, you might want to check out PostgREST as it has out of the box JWT authentication and uses actual database roles for row level authorization. "One source of truth". You could use that together with PostGraphQL if you want both REST and GraphQL! Plus you can store JSON data in columns these days so its all good!
So many options!
Good luck!
You can embed Horizon in a node app and only use a subset of its features: http://horizon.io/docs/embed/ . You should be able to piggyback on the authentication pretty easily. It would be harder to piggyback on the permissions if you're implementing your own REST API, because the permissions system only controls access to collections.
Personally I suspect it will be more trouble than it's worth if you're embedding it just for the authentication.