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:
Related
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
Background
I have nuget packages in a private nuget feed on azure devops and I try to consume them from on-prem TFS.
This worked, but only for a few hours
In azure devops, I navigated to Artifacts -> Connect to feed and clicked the link "Download NuGet + Credential Provider". When running CredentialProvider.VSS.exe -U URL_TO_FEED I got a jwt token.
In tfs on-prem, I navigated to the "NuGet restore" step in the build definition. At "Feeds and authentication" I selected "Feeds in my NuGet.config" and at "Credentials for feeds outside this account/collection" I clicked "Manage". In the "Add new Team Foundation Server/Team Services Connection" dialog box I selected "Token Based Authentication" and filled in the values. I put the token I got from CredentialProvider.VSS.exe in the field "Personal Access Token".
The nuget packages were restored so everything seemed good, but the next day it didn't work any longer since the token was only valid for a few hours (I decoded it to verify).
Question
How am I supposed to make this work? It seems strange to use a "Personal Access Token" since it shouldn't be related to me as a person (in case I leave the organization for example). The username for the token generated by CredentialProvider.VSS.exe was VssSessionToken which might indicate that it's not a personal token related to me, but I don't know.
The PAT (Personal Access Token) are pretty much the way to go for Azure Artifacts feeds as they are the generic to provide access to different parts of Azure DevOps.
If you are worried about the fact that they are personal it might be a solution to use a service account to generate the tokens.
If you want a PAT that has a longer lifetime it might be easier to create one yourself (see https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/nuget-exe?view=azure-devops&tabs=new-nav#add-a-feed-to-nuget-2 for instructions)
In short you will create a PAT with the 'Packaging (read)' permission, as to limit the possibility of abuse.
Two things to take into account:
PAT's always have an expiration date so you will need to keep track of that.
PAT's give access to the Azure DevOps Api as the user that created them, so make sure they are not accessible and limit the permissions as much as possible.
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.
How can I add a limited access account for jenkins automation when I'm using Global GitHub OAuth Settings?
I'm using GitHub OAth for login to jenkins and I have python jenkinsapi scripts that I want to run as a user with read only access. At present, all my users are github users.
I can create a github account without access to my repositories and then limit that accounts access to jenkins but this seems cumbersome.
Is there a way to use multiple security realms or to create local users?
It seems that when jenkins contains a local user, that the plugin uses this first (plugin-source)
If you look at Manage Jenkins->Configure Global Security, you can see that you can select only one security realm.
I would say, for Jenkins use create a github service account specifically that user can be restricted to just a few repositories. You can also look at matrix based security or project based matrix security if you want to restrict authorization further