I'm doing some testing with a new Cloud Service and for some reason in my certificates I'm getting a bunch of these entries
DC=Windows Azure Service Management for Extensions
All have different thumbprints. Doesn't seem to be affecting anything.. but annoying to have in the list.
What are they? How do I stop them from auto populating?
The things you could do through Azure Management Portal (like creating Cloud Services etc.) can essentially be done through Azure Service Management API. Management certificates are one way of authenticating your Service Management API requests: http://msdn.microsoft.com/en-us/library/azure/ee460782.aspx#bk_cert.
There are many reasons that these certificates are created automatically. Some of them are:
Whenever you download a publish setting file, a new management certificate is created.
If you try to connect to your cloud service VM via RDP through portal, if you don't pay attention, a new certificate is created for RDP. I'm not 100% sure but same thing happens when you update Azure Diagnostics as diagnostics is again an extension.
Related
Stuff in Azure are secured with Service Accounts. In order for me to see stuff I need to download the Service Account certificate and then log in via the Azure CLI using the extracted certificate and the Service Account Application Id. So now I can see everything the Service Account can see, great. But it is a pain in the neck and slow. So my question: Can I use the same certificate and credentials to log into the Azure Portal website so I can browse around using the web browser instead?
Using a Service Principal for interactive logins to the Azure Portal is not possible - which is by design. In order to be able to see the same resources as the Service Principal through the Azure Portal, you would require a user account that holds the Azure RBAC Reader role against those resources that are in scope of the Service Principal role assignments.
As you mentioned performance being an issue with using the Service Principal login, you could try Azure Resource Graph queries. These are supported by Azure CLI, Azure PowerShell as well as all the major Azure SDK's. Obviously, this won't bring you the visual experience like the Azure Portal but might resolve the performance piece maybe.
However, requesting/creating a user account that has the corresponding RBAC roles assigned would be the only way to allow you to see the resources through the Azure Portal.
I am trying to follow https://blogs.msdn.microsoft.com/tfssetup/2016/04/01/build-and-deploy-azure-web-apps-using-team-foundation-serverservices-vnext-builds/.
I have no issues deploying the web app manually from Visual Studio using PublishingSettings and Publish option. I just want to automate the process and I am stuck at this step:
The article clearly advises
Select the Certificate Based connection. This is very important when
you are trying to deploy. Credential based Microsoft Account
(#outlook, #hotmail) are no longer supported and only Organizational
accounts are. Even then, if they use Two-Factor Authentication(2FA),
the build will fail trying to connect to Azure.
This is correct and if I try to use Credentials, my deployment fails with unknown_user_type: Unknown User Type
There was an error with the Azure credentials used for deployment. message.
So >> Certificate. But in my PublishSettings file there is no Management Certificate and as per this article
Azure Management Certificates and Publishing Setting files (...) are
only intended and limited to manage Azure Service Management (ASM)
resources
I tried this option:
But VSTS is not connected to the Azure environment (considering that Azure belongs to one Customer and VSTS to another, is it even possible?).
My questions:
* Is it the deployment somehow possible with PublishSettings file?
* Should the "Credentials" option work if I am using an organizational account Me#Company.com?
* How else can I try?
EDIT
Your solution could be creating a service principal in Azure and connect it to VSTS. The automatic Build from VSTS should then be published to Azure automatically. Here you find how to setup the service principal and connect it to VSTS: https://www.petri.com/connect-visual-studio-team-services-azure-using-service-principal-name
I am not sure right now, whether you are using TFS or VSTS?! When I publish a Web App in VSTS, the ARM Service Endpoints works well:
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
A mechanism very similar to AWS instance profiles is Managed Service Identity (MSI) for Azure, which was announced in September 2017, though at the time of this writing, it is still in preview. I didn't try it out yet, but it does work the same way as instance profiles on AWS do, by automatically authenticating the VM to a meta-data service and allowing you to query for additional credentials without having to hardcode it into your code or image.
Azure also supports IAM.
Microsoft Azure identity and access management solutions help IT protect access to applications and
resources across the corporate data center and into the cloud. This enables additional levels of validation,
such as multifactor authentication and conditional access policies. Monitoring suspicious activity through
advanced security reporting, auditing and alerting helps mitigate potential security issues.
More detailed information please refer to this link.
Update:
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). I have a similar question with you, maybe you could check.
I found Azure is not support instance profile like aws.
If bind a role to instance on aws, aws system will generate a temporary api access token and write to metadata server.
Aws sdk will auto fetch access token from metadata server, so a service that uses aws sdk does not need to configure sdk's access token.
But Azure's IAM and SAS(shared access signature) and metadata server, is not support mechanism like above.
We have developed and tested our webroles in our Free trial Azure cloud.
We now have to deploy the webroles to Company A Azure cloud. Company A is open to creating IIS VMs for our deployment but will not share username/pwds with us to publish our Webroles to their cloud.
This should be a pretty common scenario, would like to hear from folks who have solved it in their deployments.
How do we publish web roles to a pre-existing VM?
This isn't how Web Roles work. A Web Role (along with any other defined roles) is essentially a bundle of code, startup scripts, binaries, etc. that are needed on the VM. The VM itself is stateless: It's started up as a fresh (up to date) copy of Windows Server, and your code is executed. Anything needing install is done via your startup scripts.
You cannot push a Web Role independently to an existing Virtual Machine. You'd need to take your actual code project (e.g. asp.net) and publish that to a pre-existing VM, without any of the Web Role scaffolding. How you do that would be up to you (and the folks who are managing these VMs).
I guess there is a confusion with different concepts.
From what I understand you have already deployed your cloud service and associated web roles to a trial azure subscription. You were able to do that because you are the admin of the subscription. If you need to deploy the same set of roles and the cloud service to one of your customers azure subscription they will need to setup your account as a co-admin so you can follow the same deployment procedure you did with your trial subscription. They don't need to give you a user/pass pair. They just need to give your LiveID or appropriate credentials a temporary co-admin permission to do the deployment on their behalf. They can do this in the azure management portal.
I created an empty Azure cloud service and I want to allow other developers to deploy to it. So far the only route I can see is adding the developers as Azure subscription administrators. I would rather give them more specific access to the cloud services only.
No such functionality exist today which will allow you to grant/revoke permissions at the cloud service level. Once a developer is provided access to the subscription, they would have access to all the resources under that subscription.
There's a REST API behind cloud service deployments and all the tools (including Windows Azure Portal and Visual Studio) consume this API for creating deployments. One possible solution would be to build your own solution consuming this API. In this solution you will implement access control based on your requirements so that when your user use this service, they will only see the cloud service they're assigned to and can only manage that cloud service. There's a managed library for consuming this API. You can find more information here: http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries.
It seems that if the original developer downloads the publish profile from Azure (it's an xml file that with a .PublishSettings extension), you can copy the userPWD from that file, give it to another developer and they can paste it into the password field in the Connection section of the Publish dialog.
The userPWD is a string that looks something like this:
EFFCLfDqDKHlXcA2YDZPvX4BZXWFaobxaLN0aPJd4HCfa8WxlqEkt2yywBsx