I am kindly seeking guidance and a little help on implementing XACML ABAC with Active Directory authentication on Kubernetes.
We have a major project at the hospital we are working on, and authorisation and permissions are are great concern. After a digging around, We determined that ABAC and XACML would be our best shot and handling consents and permissions.
However we also have Active Directory server from a different unit, and it is what we are meant to use at the moment for authentication into the cluster . We are meant/want to run a kubernetes cluster on which different pods with different apps are to run. Any guidance and help for us? Could Fortress be an option towards achieving this? (ABAC)+(external LDAP server/ Active Directory) on Kubernetes.
Thank you.
Related
We have a bunch of Windows server applications that currently handle secrets as follows; our apps are in C#.
We store them in settings files in code
We store them encrypted, using a certificate
The servers have this certificate with the private key, so they can decrypt the secret
We're looking at implementing Hashicorp Vault. It seems easy enough to simply replace the encrypt-store-decrypt with storing the secret in Vault in the KV engine, and just grabbing it in our apps - that takes that certificate out of the picture entirely. Since we're on-prem, I'll need to figure out our auth method.
We have different apps running on different machines, and it's somewhat dynamic (not as much as an autoscaling scenario, but not permanent - so we can't just assign servers to roles one time and depend on Kerberos auth).
I'm unsure how to make AppRole work in our scenario. We don't have one of the example "trusted platforms" or "trusted entities", there's no Nomad, Chef, Terraform, etc. We have Windows machines, in a domain, and we have a homegrown orchestrator that could be queried to say "This machine name runs these apps", so maybe there's something that can be done there?
Am I in "write your own auth plugin" territory, to speak to our homegrown orchestrator?
Edit - someone on Reddit suggested that this is a simple solution if our apps are all 1-to-1 with the Windows domain account they run under, because then we can just use kerb authentication. That's not currently the way we're architected, but we've got to solve this somehow, and that might do it nicely.
2nd edit - replaced "services" with "apps", since most of our services aren't actually running as Windows services, just processes. The launcher is a Windows service but the individual processes it launches are not.
How about Group Managed Service Accounts?
https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
Essentially you created one "trusted platform" (to your key vault service).
Your service can still has its own identity but delegation to the gMSA when you want to retrieve the secrets.
For future visibility, here's what we landed on:
TLS certificate authentication. Using Vault, we issue a handful of certs, each will correspond to a security policy/profile, so that any machine that holds that certificate will be able to authenticate and retrieve the secrets they should have access to.
Kerberos ended up being a dead-end for two reasons. The vault.exe agent (which is part of this use case) can't use the native Windows Kerberos SSPI, so we'd have to manage and distribute keytab files. Also, if we used machine authentication, it would blow up our client count (we're using the cloud-hosted HCP Vault, where pricing is partially based on client count).
Custom plugins can't be loaded into the HCP, of course
Azure won't work, it requires Managed Identities which you can't assign to on-prem machines. Otherwise this might have been a great fit
Has anyone come up with a complete solution to protect and replicate VMs from on-prem (either VMware or HyperV) to Azure using either the REST API or the Powershell module?
I recently completed a POC with ASR and was able to replicate a couple dozen VMs associated with three different applications. I replicated out of VMware and into Azure. I was able to failover and failback successfully.
I did all of the POC work using the GUI (portal.azure.com). Now I have to figure out how to protect ~2000 VMs and there is no way that I am going to do that with the GUI. But the MS documentation has me running in circles.
(https://learn.microsoft.com/en-us/azure/site-recovery/)
It would be very helpful if any of you can share the sequence of steps to protect and replicate a VM. The MS documentation does not lay out how the various components (fabrics, protection policies, protection containers, protection items, etc.) are related to each other.
I do not need specific syntax. The documentation does a passable job of detailing the syntax. I could use some guidance on the task sequence.
If it helps to understand the bigger picture, my intention is to use a System Center Orchestrator runbook to ingest a CSV list of VMs, parse that out into input for the Azure REST API / Powershell, and then enable protection.
Thanks in advance for any assistance or guidance that you are able to provide.
You can find recovery service API documentation here:
https://learn.microsoft.com/en-us/rest/api/recoveryservices/
When you have one definition put in place(manually from portal), you may also be able to study it from resource.azure.com to see how properties are composited. *not all resource available thru this portal
After that, you should be able to create template for either REST call or Resource Manager, depending on preference.
How can I avoid the 401 error, access denied, when i try to preform sync from one environment to another? I think there is an edit to the web.config that will allow this, but I am not sure what I need. I came across the same question in DevNet, but there wasn't an answer. https://devnet.kentico.com/questions/content-staging-windows-authentication-problem.
I got this to work. Sync points to /CMSPages/Staging/SyncServer.asmx. In IIS, I adjusted the Authentication on CMSPages. I enabled Anonymous, and disabled Windows Auth.
I did this on my DEV instance, and i'm syncing from PROD. So far, so good.
Did you set up the Staging user / credentials properly on the target and set them properly on the source site?
Is staging enabled on the target server?
Does both environments have Full Access/Control with their app pool processor?
Is it only some tasks or all tasks that you get this?
Is basic authentication also allowed on the sites (may be needed, but unsure on that)
I have created a space and a BigInsight cluster on Bluemix. In order to test Knox, I need multiple users for authentication. Is it possible to create users in Bluemix Biginsight service? The ID that is provided to access the cluster does not have root access. Also, it would be helpful if someone can explain in detail how the admin-related task(adding more components like Hue,Drill using yum commands) could be performed in Bluemix Biginsights service. Thanks in advance.
I am guessing here that you have created a Bluemix Biginsights Basic (Beta) plan.
This service is a single user service and cannot have multiple users.
In addition this service is a managed service and installation of software by the user is not allowed.
This service comes with preconfigured settings and pre-installed softwares that is fixed. If you do need something apart from this, I would suggest to open a Biginsights service ticket through Bluemix Support page with a request for it and why you need the software.
The product management team will look at it and see if they can be preinstalled in the future release.
These installations will not be done on a any Basic (Beta) plan for individual clusters.
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.