I want to clone Azure Key vaults from account A to account B.
Can someone guide me in how to clone the key vault? Is there any procedure for it?
Or, otherwise, how could I recreate the key vault in the account B manually?
You can move resource across subscirption under same tenant , The target subscription must exist and in enabled state.
You can refer this Checklist before moving resources
There are some important steps to do before moving a resource. By verifying these conditions, you can avoid errors.
The source and destination subscriptions must exist within the same
Active Directory tenant.
I have deployed using ARM templates by removing secrets from it, secrets has to be added manually
Related
How to Access Azure Devops Artifact Feed from different Organization with out PAT token.is there any other alternative to authenticate. because pat tokens will expire in due time.
Depends on how you want to access it. In the security settings of an Azure Active Directory backed Azure Repos feed you can set the access type to "Anyone in my AAD".
You can also edit the feed-view settings to make the feed available to a whole org:
Looking for guidance on what items to store in a simple configuration file versus an Azure Key Vault?
For example, an SQL Database name should be stored in a configuration file while its password should be stored in a KeyVault. Is this correct?
Should there be a key vault for each environment (I think not) or simply one for production and one for non-production?
Yes, you can just store the password of SQL Database in azure key vault and store the database name in configuration file, or we can store the whole connection string of the database in azure key vault.
For your second question about should there be a key vault for each environment, I think it's unnecessary for us to create multiple key vault for each environment, you can just separate them with several different names in one key vault.
Anything that should be protected (passwords, certs, API keys, etc..) should be in a Key Vault and have strict access policies assigned to it.
Agree with Hury on the first half; however, disagree on the one key vault for all environments. Different access policies will be applied for different environments.
Your developers may want access to the Key Vault for the dev credentials. As such they'd have an access policy to the dev Key Vault. I would not want to grant them access to a production Key Vault, which would give them access to all the keys in it.
Key Vault is a globally available resource. So if you have multiple instances in different regions connecting that is fine as you wouldn't need to have a separate Key Vault in a different region from a disaster recovery and availability standpoint.
Here is a similar quesiton and also link to Microsoft best practices which supports this
What is the benefit of implementing Active Directory based Security to servers like Jenkins?
The only benefit I can think is the admin of the sever does not need to add/remove users because user can login themselves using AD credential.
But In my case I do not want to have the whole company access my server. the server is only used by my team. How can I disable the whole company from login in. (case1)
Besides, I want to grant different permissions to different members in my team. The new members get less permission, the experienced team members get more permissions. I believe this is very common. But using Active Directory based Security looks like they get the same permission because they are in the same groups (case2)
So why should I use Active Directory based Security? Can I resolve the above two cases in a server configured with Active Directory based Security?
Some corporate environments make this a security requirement. In said environments they usually have an internal request system where users can request they have their credentials added to an appropriate group for access to Jenkins. This is better than Jenkins own database and having them email you, the Jenkins administrator.
Once AD Authentication is configured in Jenkins and appropriate groups created in AD you can do a one-time setup of those groups with the Role-Based Strategy plugin in Jenkins and define what those groups have authorization to do.
Plan your groups well and it is a function that you will no longer have to worry about.
Warning: Be very careful when switching over from Jenkins own database user authentication to AD authentication. If you don't get the BindDN details just right you can get locked out.
In our GitHub we have around 20 repositories. For the CI Build we have enabled Git polling option.
Our Jenkins master has attached with multiple nodes. For Git Polling we usually add our Jenkins Master ssh key to repective user's GitHub under settings SSH key section. While adding the key getting Error: Key already in use. Let me know to add the same.
As per error message for other repository build we have already added our Jenkins Master key with different user's
account.
A SSH key can only be attached to a single user on GitHub, since it is used to authenticate and authorize this user. There is no way to add to multiple accounts.
GitHub provides a guide about dealing with SSH keys for automated scripts here: Managing deploy keys. The two interesting options are:
Typically, you would use deploy keys to gain access to a repository from a server. Deploy keys have a similar restriction as a user's SSH key though, and can only be attached to a single repository. This reduces the potential damage that can be done if the key is compromised. For build servers they are often not well suited, because it is often not possible to configure authentication per repository.
For your use case, a machine user seems to be the best option. This is a dedicated user account that is only used by your build server. Make sure to use a strong password and two factor authentication for this account, and add Jenkins' master key to it. You can then add the machine user as a collaborator on the repositories you need in Jenkins.
With regards to security, be as restrictive as possible: only the repositories that are required, and only with read permissions. This is also the reason why you should use a machine user instead of an actual user account. For Jenkins, you (usually) don't need write access to a repository. By limiting the access rights for the server key, the impact of a compromised key is reduced.
I am doing some initial research and I am unable to find a clear answer for my problem. The plan is to have multiple environments, (i.e. Dev, Prod, and QA) would I need to have a new instance of Azure Key Vaults for each environment or would I just be able to share the data between them?
I would rather advise to use separate Key Vault instances for the different environments. You can avoid "mixing" secrets across environments by mistake and you have clear separation.
Microsoft officially recommends this approach too:
Our recommendation is to use a vault per application per environment (Development, Pre-Production and Production).
You can read more in the official documentation
Multiple resources/entities can access a single Key Vault instance - provided they're all in the same location (data centre).
You may choose to segment your keys, secrets and certificates, either by placing them in different Key Vaults or by using different access methods/identities, however that's not necessary.
The only time you need a separate Key Vault instance is when the resources/entities accessing it are in another location (data centre/region).
It's worth noting that you don't need to worry too much about provisioning Disaster Recovery for resources using Key Vault, as the SLA Microsoft provide is unsurprisingly good: https://learn.microsoft.com/en-gb/azure/key-vault/key-vault-disaster-recovery-guidance. One caveat to that would be if you're running IaaS/PaaS instances and want to run a DR fail-over yourself to another data centre, at which point you'd need to manually migrate the keys/secrets/certificates in your main Key Vault into another instance (and re-point your VMs accordingly)