looking the IBM istio appid adapter for auth purposes, i could see that the adapter generates the cookie in code using a random hashkey thats created at the adapter's startup.
If i want to run multiple instances of the adapter for high availability, won't that be problematic as they don't share the cookie signing key ?
Looking at the source code what is the config.proto in config\adapter\config.proto used for ? What could one potentially use it for ?
You're absolutely right. At the moment adapter can only run as a single instance, as there's no cookie sharing mechanism implemented yet. This is something we intend to address in future releases.
Using a common signing key for cookies is supported but undocumented.
The adapter looks for k8s secret named appidentityandaccessadapter-cookie-sig-enc-keys in the istio-system namespace
Related
My app uses a SPA client and Phoenix/Elixir backend, with jwt authentication (via Guardian library). The app is deployed using Docker on GCP.
I'm having the below issue:
I'm an authenticated user that has been issued a jwt. Everything works fine.
The production application's docker image is rebuilt, redeployed, and the server is restarted.
My jwt token issued before the rebuild is no longer valid.
I'm having trouble finding what would be causing this. Looks like the secret key used in config.exs Guardian config will always be the same across builds.
Any help is appreciated!
Either the contents of the payload are being used to validate the message, and some field has changed in a way that the JWT is considered invalid by the server, or the secret actually has changed and your assertion is not correct.
The way I would problem solve this is by using a pre-developed tool to verify the JWT. Either your secret key can be used to validate the signature or it can't. No need to "guess".
I have configured my service fabric services to use Azure Key Vault for configuration. If, after the app is deployed, I change the config in Key Vault, how do I then restart the affected service so it can pick up the new config value?
Or is there another way altogether?
The best way to handle configuration on SF is use your application parameters file for this, if you use a continuous deployment pipeline like VSTS, you could use release variables to set these values for you and deploy a new version of your configuration file and let SF do the rest.
But in case you still need to use Key vault:
if you are using asp.net core, Using Azure Key Vault to store secrets are like loading configuration files, the values are cached until you reload it.
You can use the IConfigurationRoot.Reload() to reload the secrets from your key vault new values. Check it Here
The trick now is to make it automatically you have to:
Enable Key Vault Logging to track the changes, this will emit logs once you update the key vault. check it here and here .
And then:
Create an endpoint in your API to be called and refresh the secrets. Make it secure to avoid abuse.
Create an Azure function to process these logs and trigger the endpoint
Or:
Create a message queue to receive the command and the system read the message to refresh the settings
Or:
Make a timer to refresh on specific periods(I would not recommended this approach because you might end up with outdated config, but it is easy and useful for quick test scenarios, not production)
Or if you prefer more custom designed solution, you could create your own ConfigurationProvider based on KeyVault and do the cache logic according to your app architecture and you don't have to bother with the rest. Please refer to the Asp.Net source here for this.
The documented way to provide configuration to your services is by using the 'configuration' part of your application package.
As this is versioned, it can be upgraded, without requiring your services to be upgraded or even be restarted.
More info here and here.
In cloud foundry how can I get the client_id and client_secret code.
This will be used in Basic authentication instead of passing the user and password for respective api calls
In general, this is something that you would get from your platform administrator. He or she would be able to provide you with a properly configured client id and client secret to fit your needs. If you are not the administrator, then you won't be able to do this.
If you are an administrator, read on. There are many existing client and secret pairs within a Cloud Foundry platform. It's also possible, and suggested, to create custom client and secret pairs for use with non-platform apps. You shouldn't use a platform client for your custom app, you should use your own custom client, that way if the client is compromised you can delete it or change the secret.
All of this, viewing & managing client data, is done through UAA, so I'd recommend starting with the docs on UAA. Make sure that you understand the concepts. You may even want to take a step further back and review concepts of OAuth2 as well. Understanding OAuth2 will make working with UAA much easier.
https://docs.cloudfoundry.org/uaa/uaa-overview.html
After that, you'll need the uaac (i.e. UAA client) installed.
https://github.com/cloudfoundry/cf-uaac
Once you're familiar with UAA & have the client installed, this doc on how to manage clients should provide you with instructions to view or create a new client.
https://github.com/cloudfoundry/uaa/blob/master/docs/Sysadmin-Guide.rst#manage-client-registrations
You will need admin role to be able to create a client or get its details.
Refer https://docs.cloudfoundry.org/api/uaa/version/4.7.1/index.html#clients to see various api to manage and create clients.
You can also use the uaa client to get the client details.
Refer https://docs.cloudfoundry.org/uaa/uaa-user-management.html for more info.
Spring Boot - 2.0.0.M3
Spring cloud - Finchley.M1
I want to know if someone is using Spring Cloud config server with both vault and git support in a production setup using Database storage backend.
I have evaluated Spring cloud config using vault and contemplating whether to go for Oracle JCE to encrypt username/pwd or Vault and seek suggestions on the same. we are working on Springboot/microservices.
Following are my findings -
Vault will introduce an additional layer and thus will introduce additional usecases of security, auditing while communicating with Vault.
Spring cloud Config actuator endpoints are broken for the milestone release at this point for generation of encrypted values and /encrypt /decrypt may not work if we go for Oracle JCE support so we generate encrypted values through stable versions.
We do not wish to use consul server and are trying to use Cassandra as Storage backend.
I used Vault Authentication backend using AppRole and generated a Token (different from root token as it's unsafe to use the same) with read permissions. However, Spring Cloud config at the moment support only Token based authentication from client side. That means we first generate token from Vault and then pass it as commandline/env variable.
Some additional points of concern are expiry of token (though we can have non-expiry token not sure about pros/cons), restarts, safety issues, instantiating new microservices. There is no provision of dynamic tokens/authentication at cloud config side.
For milestone release i found that the client side encryption/decryption is not working as of now using recommended inclusion of RSA jar. Here is the ticket i opened.
https://github.com/spring-cloud/spring-cloud-config/issues/805#issuecomment-332491536
These are some of my observations, please share your thoughts if there is any case study/whitepaper that address spring cloud config vault usecases, setup and challenges for production micro-services environment.
Thanks
Thanks for reaching out to me. One think I would state is that the App Role backend utilizes two distinct tokens, and indeed spring-cloud-config-vault does indeed support this functionality, see: http://cloud.spring.io/spring-cloud-vault/single/spring-cloud-vault.html#_approle_authentication. I leverage vault in the same way I leverage config server, as per the documentation. I don't encrypt any values in my config, I just don't put them there. I put the secret values in vault and let it serve config. As long as keys don't collide, you don't have to mess with anything, otherwise you may need adjust the priority so vault wins, again see the documentation that I pointed to above. I wouldn't mess with encryption/decryption in spring-cloud-config personally. Because you have to check the keys into SCM or distribute them to your teams for local development, you lose the value of having these keys IMO.
Thanks Spring Cloud vault does support but not Spring cloud config with Vault. Only way seems to be passing X-Config-token from Microservice to Config Server. We are bit skeptical with this part of generating tokens manually or through script. Especially with containerization and when new MS instances will be spawn. Not sure about this approach especially in production setup.
I have ACL on for Consul, and have tried many ways to specify the token to use for service discovery. The config ACL token works fine, and the discovery ACL token works for registration (I can see my services in the Consul UI). I see the code for AgentConsulClient.agentServiceRegister() supports the token with this:
UrlParameters tokenParam = token != null ? new SingleUrlParameters("token", token) : null;
Nothing similar is supported in CatalogConsulClient, as far as I can tell. When called from Spring Cloud's ConsulDiscoveryClient, no token is passed, regardless of how it is set. Logs show the call being made without the token, and getting back a valid response with none of the registered services listed. I don't see how to have ACL on for registration but off for discovery. What am I missing? Is nobody actually using ACL if using discovery? (It works fine in the development environment with no ACL). Do I need to edit the source to add the token support from the agent service to the catalog service? Has anybody had success doing that?
BTW, could not tag this with spring-cloud-consul. Add it if you can.
ACL support for Consul catalog services is in consul-api v1.1.11 and will be (I hope) part of spring-cloud-consul 1.0.3.RELEASE. The 1.0.2.RELEASE version still uses consul-api-1.1.10. Update: confirmed to be in Camden.SR3.
Gradle:
'com.ecwid.consul:consul-api:1.1.11',
'org.springframework.cloud:spring-cloud-consul-dependencies:1.0.3.RELEASE'