Anyone have insight on how to implement Two-Factor Authentication when using Service Fabric Explorer to access a Service Fabric cluster in Azure?
I currently have it secured with a client certificate but I haven't found ways to add another type of authentication to go with it.
per the official documentation here:
When a client connects to a Service Fabric cluster node, the client can be authenticated and secure communication established using certificate security or Azure Active Directory (AAD). This authentication ensures that only authorized users can access the cluster and deployed applications and perform management tasks. Certificate or AAD security must have been previously enabled on the cluster when the cluster was created. For more information on cluster security scenarios, see Cluster security. If you are connecting to a cluster secured with certificates, set up the client certificate on the computer that connects to the cluster.
It doesn't support MFA, I'd recommend checking out Service Fabric cluster security scenarios
You could also implement MFA on the AAD level and then using the AAD to authenticate to Service Fabric
Related
We have a cluster that runs a number of dotnet apps, one of which runs the identity server. All the other apps need to authenticate with the identity server. If the identity server was external this wouldn't be an issue as it would have an HTTPS endpoint, but internally they are all running HTTP.
With istio adding MTLS security to all the comms, do all the apps just get set with RequireHttpsMetadata = false?
Is this the correct way to setup the network with internal requests being sent as http://auth-server.default.svc.cluster.local/...?
or should they be sent as https://auth-server.default.svc.cluster.local/..., if so how?
Is there a web gui to kubernetes (on premises) that can be integrated with Active Directory (on premises, not Azure) authentication. This way RBAC would be integrated with Ad users.
I'm posting an answer based on my comment for better readability.
Such integration can be done using dex - A federated OpenID Connect provider project. In short:
Dex is an identity service that uses OpenID
Connect to drive authentication for
other apps.
Dex acts as a portal to other identity providers through
"connectors." This lets
dex defer authentication to LDAP servers, SAML providers, or
established identity providers like GitHub, Google, and Active
Directory. Clients write their authentication logic once to talk to
dex, then dex handles the protocols for a given backend.
Dex runs natively on top of any Kubernetes cluster using Custom
Resource Definitions and can drive API server authentication through
the OpenID Connect plugin. Clients, such as the
kubernetes-dashboard and
kubectl, can act on behalf of users who can login to the cluster
through any identity provider dex supports.
More docs for running dex as a Kubernetes authenticator can be found here.
You can find more about companies and projects, which uses dex, here.
As this is quite extensive topic, there is no point of rewrite all the configuration steps here. You can find a lot of well written articles about integrating kubernetes with Active Directory using dex e.g.:
Access your Kubernetes cluster with your Active Directory credentials
Authenticate Kubernetes Dashboard Users With Active Directory
I am running a web application packaged as WAR inside WildFly, with authentication configured via a secure deployment managed by the Keycloak adapter subsystem.
The corresponding client in Keycloak is configured with a service account. Now, I'd like to send requests to Keycloak (and possibly other services) using the service account and associated roles.
What is the best way to obtain a token for authentication "as the service", i.e. using the service account?
Is there a way to access the client secret specified in the secure deployment definition from the runtime context of my WAR?
Am I doing things wrong? What is the optimal approach here?
Note that I still need to be able to authenticate requests from the web inbound to the service with Keycloak.
I want to deploy Identity Server 4 on Kubernetes 1.8, and use this as a Federation Gateway between my web application and Azure Active Directory (to begin with).
If I call Identity Server from my web application using the local k8s service name, my users are redirected to the wrong Identity Server URL (containing the local k8s service name) during Sign in which clearly won't work. We are using an implicit flow.
I therefore setup a Azure Load balancer with dns name and configured Identity Server to be externally accessible with the domain name as the PublicOrigin URL.
However, my web application which runs in the same cluster cannot access Identity Server using the external URL of the Identity Server (discovery fails).
If I run Identity Server on another Kubernetes cluster then everything works fine.
My question is:
How do you properly deploy Identity Server in Kubernetes? Do I really need another Kubernetes cluster?
Note: I am using Kubernetes on Azure created with ACS engine (because we have mixed windows and linux containers).
I'm using AKS (Azure managed kubernetes) and have a single client asp.net core 2 web app in the same cluster as my IS4 service with no issues. Both webapps are fronted by Nginx with kube-lego for LetsEncrpyt TLS support, and DNS is provided by Azure DNS.
I'm not using the PublicOrigin but instead the client app's Authority (in the openidconnect setup) uses the full (external Azure) DNS name of the IS4 service. You can use PublicOrigin if you want to use the cluster service naming from your clients
GKE currently exposes Kubernetes UI publicly and by default is only protected by basic auth.
Is there a better method for securing access to the UI? It appears to me this should be accessed behind a secure VPN to prevent various types of attacks. If someone could access the Kubernetes UI, they could cause a lot of damage to the cluster.
GKE currently exposes Kubernetes UI publicly and by default is only protected by basic auth.
The UI is running as a Pod in the Kubernetes cluster with a service attached so that it is accessible from inside of the cluster. If you want to access it remotely, you can use the service proxy running in the apiserver, which means that you would authenticate with the apiserver to access the UI.
The apiserver accepts three forms of client authentication: basic auth, bearer token, and client certificate. The basic auth password should have high entropy, and is only transmitted over SSL. It is provided to make access via a browser simpler since OAuth integration does not yet exist (although you should only pass your credentials over the SSL connection if you have verified the server certificate in your web browser so that your credentials aren't stolen by a man in the middle attack).
Is there a better method for securing access to the UI?
There isn't a way to tell GKE to disable the service proxy in the master, but if an attacker had credentials, then they could access your cluster using the API and do as much harm as if they could get to the UI. So I'm not sure why you are particularly concerned with securing the UI via the service proxy vs. securing the apiserver's API endpoint.
It appears to me this should be accessed behind a secure VPN to prevent various types of attacks.
Which types of attacks are you concerned about specifically?