For deployment to Azure we need to authenticate, and we have two methods to achieve this.
1. Publish Setting File
Download the publish setting and use the Subscription Name to Set the subscription before deployment
2. Managed Certificate
Create and upload the .cer file to the management Portal.
Use the associated .pfx to be installed in the client machine during deployment, and authenticate with the thumbprints.
Can someone tell me which one is better in terms of security, manageability and ease of usage?
Related
We currently have a cert manager instance in IBM Cloud and have certificates ordered via Lets Encrypt and using the certs with our client to site vpn service . As the cert manager is getting deprecated in favour of secrets manager , we plan to create public engine in Secret manager using same Lets Encrypt CA.
In the ACME creation tool, we have the option of tageting Let's Encrypt prod and staging. Can anyone throw light on which target needs to be chosen?
https://github.com/ibm-cloud-security/acme-account-creation-tool#supported-certificate-authorities
Also, once LE is integrated with Secrets manager , will the certificates be able to be auto renewed?
LE staging is for testing your setup. Once everything works you should use production. See https://letsencrypt.org/docs/staging-environment
Secrets Manager supports secrets rotation, including automatic renewal of certificates. Some conditions must be met. I recommend to check "Automatically rotating secrets" in the Secrets Manager documentation. I have not tested it, but from reading it, LE is supported with domain validation.
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
BACKGROUND
We are about to set up a deployment server that will be used to manage Azure resources. The deployment server will run pre-defined PowerShell scripts and deploy ARM-templates.
This article describes how to use service principals and keys vaults so that the application that runs inside the deployment server securely can execute deployment scripts.
PROBLEM
Frequently, the deployment server will be updated with scripts, new pipelines, different types of configuration, code snippets, templates etc. When changes are made on the deployment server, we do not want the secrets to being exposed in any way.
A JUST IN TIME APPROACH – CUSTOM ACCESS KEY API
The functionality we are looking for can possibly be implemented with a custom access key API with the flowing workflow:
In a service request portal, a deployment ticket is signed by an
approver
The deployment server receives the signed deployment ticket
The deployment server sends the signed ticket to a custom access
key API and receives a temporary service principal and access key
The deployment server executes scripts (with the temporary service
principal)
The temporary service principal and access key is automatically
removed
WHY A CUSTOM ACCESS KEY API?
The custom access key API adds the following capabilities:
By comparison to a deployment server, the API has a smaller footprint and we believe that updates to the service will be rare and can be done in a very controlled manner.
The API can give access to the deployment server based on the exact need (subscription, resource group, etc)
The API can use digital signatures to verify the original approver of the ticket
RECOMMENDED APPROACH?
What is the recommended approach to implement just in time access for a deployment server?
I have some powershell scripts in my CI server to check the state of some WebJobs.
But I have few problems.
I'm using publish settings file, but it expires and my build starts to fail.
I don't want to use a Management Certificate that will expose all management features.
And I don't want to put my user credentials on the CI server that will also expose all management features.
There is any way to create a CI user or credential with restricted permissions?
Thanks!
Azure Functions provides a good solution to this problem. You can create a Service Principle account, with certificate login and then restrict that account to whatever actions you need it to allow (via RBAC)
You can then have an Azure PowerShell script running in Functions, that is called from a webhook from your CI engine. That way the only credentials that are stored on your CI are the webhook secret, and if your CI engine has a static IP you can verify that commands only come from that address, and drop anything else.
I am able to create VM from a custom image using Azure resource management sdk for .net. Now, I want to download the RDP file for virtual machine programmatically. I have searched and able to find Rest API for azure 'Classic' deployments which contains an api call to download RDP file but i can't find the same in Rest API for 'ARM' deployment. Also, I can't find any such Method in .net sdk for azure.
Does there any way exist to achieve that? Please guide..
I don't know of a way to get the RDP file, but you can get all the information you need from the deployment itself. On the deployment, you can set outputs for the values you need like the publicIp dns. See this:
https://github.com/bmoore-msft/AzureRM-Samples/blob/master/VMCSEInstallFilePS/azuredeploy.json#L213-215
If your environment is more complex (load balancers, network security groups) you need to account for port numbers, etc.