Almost in every OpenStack Swift documentation is mentioned that TempAuth is a solution just for test non-prod environment (however it's fully functional).
The key reason to don't use this approach in prod that user-creds are stored in plain configuration file that decrease overall security for Object storage.
On the other hand if App is using Object Storage internally (so it's only stores files in the internal infrastructure) and authentication and authorization is provided by App itself it seems such approach might be suitable for production usage.
Could you please share any other drawbacks of TempAuth usage on prod environment taking into account that object storage is internal (or add additional arguments that it's ok :) )?
I think the problem with tempauth is that,it is built in module in the Swift, and cant be used as an external authentication module in distributed swift storage systems. but keystone can.
Related
I have plans to serve the Firebase Emulator inside a proper docker image for the use case of integration and e2e test pipeline, remotely executed. In this scenario, what are the best practices for authentication in Firebase Emulator?
I've only found documentation where the emulator's configuration is directly bind to the actual project. Thus, not allowing to externally configure a anonymous emulation with the desired specifications.
My goal is the bare minimum authorization to have the setup running inside the container itself. And by minimum, I mean that even someone with directly access to the container will not have power to affect the production environment in any sense - neither to use any authentication state saved in the container to escalate privileges.
I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
I'm using two firebase projects: one for development and staging, and another for production. The Firebase CLI allows me to switch projects with firebase use _____.
For the client I'm using create-react-app and implicitly configuring firebase by using the From Hosting URLs.
The trouble comes with configuring each project's connection to third party services. For most services I have separate accounts, so need different keys (and secrets on the server), for development and production.
For firebase functions, I can use functions config vars for each project. Pretty easy.
But what's the best way to do this on the client?
create-react-app has great support for various .env files, but can I link a .env file to a firebase project rather than using their prioritization?
Or is there a way to expose the firebase functions config vars to create-react-app's start, build, and test processes as environment variables? (preferably without building all variables into the public js :-P)
What's the best way to do this?
The best way to do this seems to be to use GCP secret manager :
Secret Manager stores API keys, passwords, certificates, and other
sensitive data. It provides convenience while improving security
https://cloud.google.com/secret-manager/docs/quickstart
Beware, it's a standalone service by GCP, therefore Google charges you to store your API keys. The pricing calculation example they detail, so i'm guessing it's a typical use case, gives a monthly cost of $15.15.
That's not cheap to store dumb API keys.
The other way is to use cloud functions as you did.
The benefits of using GCP SM are that the service can be combined with audit logs, that it has a version management feature, and that you can set permission levels.
Due to there still being no support for web client reads from locally-emulated firestore at the moment, my best option for some parts of development is to allow the local functions to modify the real Firestore (in a separate dev project).
I tried the "Admin SDK configuration snippet", but it doesn't work, the reason I suppose being the mocked firebase-admin.
Has anyone documented doing this properly?
I am considering to migrate an application to Cloud Foundry since I'm tired of managing my server on my own. In my current application I use Spring Security and sessions to handle my user logins. I am however clueless on how to change my code so Cloud Foundry's multiple instances support my user logged in in a somehow stateless way (but using a token). I have looked into UAA, but it seems that this is for cloud foundry users, not users of my application.
Something OAUTH2-like seems to be a solution, but it seems I would have to rely on third parties if I want to do it in a developer-friendly way. The Cloud Foundry (or Pivotal Web Services in this case) documentation is also quite unclear on the matter.
When looking at the Spring Cloud documentation, I do find information on how to use OAUTH2 providers like Github to do things like Authentication, but it doesn't show how to actually use the Principal or how to handle stuff like Authorization (role-based).
I assume there are ways to run my own OAUTH2 service, and that would be the recommended solution, but again, there's quite a lack of documentation.
Can anyone give me some pointers?
A couple of key questions here are where is your user store currently? And what do you want to do with it moving forwards?
If you manage your own users and wish to continue doing so then, after migrating your users to the appropriate backing service and updating your app to be able to bind to that service using CFs VCAP_SERVICES env variable (also see spring cloud), our session affinity should allow you to push your app pretty much as-is. Otherwise a little further discussion is required.
Does this help:
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#sessions
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.