Is it possible to entirely disable authentication for MinIO for local and CI usage? A bit of background: We're migrating from LocalStack to MinIO and large swathes of code rely on unauthenticated access to S3 so disabling auth entirely would be the simplest.
I finally use minio policies for unauthenticated access. Read this:
https://docs.min.io/minio/baremetal/reference/minio-cli/minio-mc/mc-policy.html
For example, I use download policy for unauthenticated access allowing users only download files.
Maybe this can help you
Related
I've setup a functional Cloudflare Worker via its route and domain and am using the Worker playground and the quick editor to avoid a deployment.
However, when developing locally I cannot make a request to the worker and get a CORs error.
I’ve read all the docs and implemented most CF security features within Zero Trust. However, nothing is getting us access to our deployed Worker due to strict CORs rules. (which we want)
On my machine I am routing through WARP and it is configured for my
team name.
I have installed and configured a root access certificate, perhaps
not applicable to this issue.
I have also tried to manually auth by visiting the worker URL and
getting a login code emailed to me. Perhaps CF Access is not related
to Workers?
We need clarification because the docs do not clearly explain the flow for access to Worker URLs when working on localhost.
Community question here.
How do we develop apps with Workers and strict CORs by authenticating a computer or user?
I think you can use Transform Rules for set/remove/update CORS.
It should work for you, because according to traffic sequence diagram header modifications performs before workers.
If I set up composer-rest-server to use github authentication (as described in https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication.html), then a client of the rest server needs to authenticate against github.
If this authentication is successful, then the client acts with the business card that was specified during startup of the rest server (or with the one that was uploaded in multi-user mode).
However, ANY github user may authenticate that way! There is no control which github users may use the rest server (I would expect a configuration file with a white list etc.). Therefore ANY github user may interact with the blockchain the same way using the business card of the rest server?!
This is quite useless in my opinion. Or do I oversee something? What is the purpose of github authentication in composer-rest-server?
Before authentication there is no real access to the Business Network, after authentication there is access to add Cards to a Wallet after which there is access to the business network (controlled by ACL).
The Wallet is unique to the authenticated user, so in your github example if you open a different browser and use a different Github ID you will have an empty Wallet, and no access to the network - except to add a card.
With regard to Github it is just used as an example of a Passport Strategy for Authentication - it is used in the example docs as it is quite easy to set up and anybody can use Github. It might be useful for a public blockchain, but for many examples it might be more appropriate to use a Passport Strategy to connect to a private LDAP or Active Directory.
Is there a way to set a heroku app as private?
I would like to deploy several internal services at heroku and make them only accessible between themselves. I would like to do it this way to hide the backend from the internet access and only allow a frontend app to be accessed by users from outside.
By default, practically everyone who can guess the correct heroku domain could access the backend and attack it directly.
Update:
To be more specific: I am looking for an altenative way besides Heroku private spaces
No, you cannot do this. What you should do if you need this functionality is to secure your web applications with a protocol like HTTP Basic Auth, or OAuth2 Client Credentials. Either of these will allow you to securely authenticate requests BETWEEN your Heroku apps without leaking data publicly.
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.
I have been looking into whether it is possible to use Shibboleth/SAML with Amazon Web Services.
I'm finding very little information on this. As far as I can tell, it is possible to install Shibboleth/SAML on an EC2 server as a Service Provider.
What I am not so sure on is whether it is possible to tie all of AWS to Shibboleth - and how this would work.
My knowledge of all three are vaguely fuzzy - I've been doing a great deal of reading, but I'm not really familiar with this technology at all.
If I understand you correctly, what you are trying to do is use identity federation to grant a user temporary security credentials to perform AWS api calls. You would like your users to authenticate to your own identity provider (Shibboleth in this case), and be granted access to AWS services based on that authentication.
A good example of this that you can use as a framework is in this AWS sample code.
In a nutshell:
You need a proxy that the users connect to, passing in their authentication credentials. You would then verify them by authenticating to Shibboleth, AD, LDAP or whatever.
You need a Token Vending Machine that your proxy would then call to get a valid AWS secret key using GetFederationTokenRequest.
Your client would then use the token given to it to make the AWS api calls.
The concepts of federated identity include terms like STS, SP, and IdP, if you are looking for a starting place to research the topic more.