https://management.azure.com/subscriptions/subID/providers/Microsoft.Compute/disks?api-version=2017-03-30
this gives me all Disks of New Azure portal.
replacing the above Microsoft.Compute to Microsoft.ClassicCompute does not give me the classic portal disks as there is no resource type called disks under classiccompute namespace.
what is the alternate to get classic portal disks?
Have tried https://management.core.windows.net/subid/services/disks but this uses a different auth mechanism all together is there any other endpoint?
As you want to get the classic disks so we can Azure service management REST API that you mentioned.
https://management.core.windows.net/subscription-id/services/disks
How to authenticate Service Management Requests please refer to the official document.
Use X509 Certificate - You can always use X509 Certificate based authorization to authorize your SM API requests
X509Certificate2 certificate = GetStoreCertificate(Thumbprint);
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);
request.ClientCertificates.Add(certificate);
How to create a new self-signed certificate please refer to document
We also need to upload the certificate under subscription.
The following is my test result via postman.
Other related links:
manage.windowsazure.com vs. portal.azure.com
Related
Many of my (confidential) apps are talking to each other via the client credential flow.
They request a token from the Azure Identity platform and use this token to authenticate against another app.
A while ago I used client secrets to do so, but later I read that this is not recommended for production environments.
For this reason I changed to self-signed certificates that are valid a longer time.
Those certificates are generated by myself with Azure Keyvault.
However, also this is not recommended.
Microsoft states that that in production environments you should use certificates that are signed by an official CA.
If I now use Lets encrypt, this will expire all three months what is also not such a nice solution.
My questions:
Why is the client secret not recommended in production environments?
Why is the self-signed certificate a problem? I do understand this in matters of HTTPS, but where is the security breach if its used for client credential flow? In my case I am the owner of the app and the app registration.
Do I need to buy a certificate that is one-year valid to do it "the right way"?
Do you have any source of best practices here?
• Client secrets include application credentials, SSH keys, API keys, database passwords, encryption keys, connection strings and so on to connect various resources and access the data or functionality for achieving the designated purpose of that application. Thus, if these are breached, they can put your application at great risk of compromise. Also, the client secret generated in Azure AD and used in APIs for connecting to Azure AD for authentication and authorization purpose is listed and mentioned in unencrypted form in the API code itself. Though, we have an option to store that secret in a key vault and refer to that secret through either managed identity or RBAC assignments, but their credentials too can fall in wrong hands and let the application be vulnerable if the managed identity is a user assigned or even if then access scope of the secret is not well defined according to the required specific need. Thus, client secret is not recommended to be used in a production API.
• In client credentials flow, applications are directly granted permissions by an administrator to perform a certain action regarding the API to be called through it via certificate or federated credentials. Thus, when using a self-signed certificate in client credentials grant scenario, the administrator has granted the daemon app requesting access to other API all the required privileges regarding accessibility of code, API, permissions, data, etc. which can result in poor validation and misuse as the it is very easy to generate a certificate’s key pair without reasonable entropy. Also, protecting the private key of the key pair appropriately to its use and strong validation of the same is not promised in a self-signed certificate due to which it is not recommended in client credentials flow.
• For best practices regarding web app service deployment, please refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/app-service/security-recommendations#general
It explains the best security recommendations for deploying a web app service.
I'd like to use some of the more advanced features of the REST Dataset in Azure Data Factory (mainly pagination), but I can't see where to use Certificate Authentication. I have an HTTP Dataset working well with Certificate Authentication, but the only options seem to be:
Anonymous
Basic
AAD Service Principal
Managed Identity
Is there some way to use the AAD Service Principal or Managed Identity with a certificate? Maybe I can do this using the Advanced settings?
The docs say that the HTTP connector is "less functional comparing to REST connector" but this seems to be a pretty big omission from the REST version.
Is there some way to use the AAD Service Principal or Managed Identity
with a certificate? Maybe I can do this using the Advanced settings?
SP and MI can't be applied for the certificate authentication, for AAD instead. please refer to this simple blog.
Based on the REST Connector document,it only supports above 4 types of authenticate options. If you want to carry certificate with request,please use HTTP connector.
We have a lot of user P12 files (certificates) for each clients/tenant and we would like to store it securely. We don't use cloud solution like Amazon, Azure Keyvault or other datacenter solution but a hosting company.
Do you have any solution ? Vault from Hashicorp
You can use Vault to manage your own PKI and issue certificates instead. In fact, it is more than that,
From using Hashicorp Vault to manage PKI and issue certificates
Vault allows you to manage an entire Public Key Infrastructure (PKI)
to ensure secure communication among different services. This allows
companies to easily setup their own certificate authority (CA), revoke
or issue new certificates using simple API calls, thus dumping the
painful process of constantly generating self-signed certificates.
You can checkout this guide for the process of using Vault to generate and issue certificates.
I need some help with deploying a Service fabric app from Team Services to Azure.
I’m getting the following error from the Agent in Team Services (see screenshot below):
2018-06-22T13:17:13.3007613Z ##[error] An error occurred attempting to
import the certificate. Ensure that your service endpoint is
configured properly with a correct certificate value and, if the
certificate is password-protected, a valid password.
Error message: Exception calling "Import" with "3" argument(s):
"Cannot find the requested object.
Please advise.
Here is my Service Fabric Security security page, don't remember where I set up the password needed on the VSTS side but I took note of it and believe it's correct.
Here is the Endpoint page on the VSTS side:
Issue resolved with the help of MS Support by creating a new Certificate in the Key Vault and Adding it to the Service Fabric, steps:
Azure Portal:
Home > Key vaults > YourKeyVault - Certificates: Generate/Import
Generate new key with a CertificateName of your choosing and CN=CertificateName as Subject.
Home > Key vaults > YourKeyVault - Certificates > CertificateName
Select the only version available and Download in PFX/PEM format.
Power Shell: Convert to Base64 string, CertificateBase64
[System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes("c:\YourCertificate.pfx"))
Home > YourServicefabric - Security: Add
Add the Certificate you created as Admin Client by providing 's thumbprint.
VSTS/TFS:
Build and release > Your pipeline: Edit
In the Deployment Process Service Fabric Environment click Manage for Cluster Connection and add a new connection. Besides the other information, in the Client Certificate paste the previous CertificateBase64.
Check the Service Endpoint in VSTS:
Whether it has a properly base64 encoded certificate, with a private key.
Also, check if the provided passphrase is correct.
Also, check if the service endpoint is configured as tcp://mycluster.region.cloudapp.azure.com:19000.
Check if the thumbprint is correct.
According to the documentation it only seems possible to authenticate against the windows azure service management API by attaching a certificate to each request which I previously have uploaded to the management portal.
The new management API has been built using the service management API, but it uses windows live authentication. Is it possible to use windows live to get the windows azure subscription ID and the certificate, so I can use the same authentication mechanism the management portal uses?
What makes you think that the Service Management API uses Live ID for authentication? It is just the portal that uses Live ID for authentication.
If you dig a bit you will notice that all the service requests from the management portal are made against https://manage.windowsazure.com/Service while The Base URI for management service is: https://management.core.windows.net
So, No, you can't authenticate against the Management API with Live ID. Moreover, it is the Management API is not new. The portal is New. The management API has been there for a while and is updated from time to time to reflect new services that are coming.
UPDATE AFTER THE 2 COMMENTS
Following Gaurav's explanation I will just add a simple architecture diagram (super simplified and totally my thought, but this is how would I build it in very minimalistic way):
[User's browser (portal)] ==> Sends XmlHttpRequest (AJAX) to ==> [Portal Service]
then
[Portal service backend] ==> signs request with predefined certificate and sends request to ==> [management.core.windows.net/subscription-id/whatever/service/command]
This actually is a very common practice to provide UI to a (web) service.
This way both conditions are implemented:
You use Live ID to authenticate with the portal
The Windows Azure Service Management API are yet, still and only protected by a Certificate.