We are in the process of updating an expired Service Fabric cluster primary certificate. We have read most of the documentation and searched the web, but some things are still unclear.
What's the idea behind having a primary and secondary certificate to begin with?
The recommended way to update the certificate seems to be by adding a secondary certificate to the cluster (Add-AzServiceFabricClusterCertificate).
Will the cluster automatically make use of the new (secondary) certificate with the furthest into the future expiry date? I think that's what the documentation is saying...
If so, will the secondary certificate become the primary certificate? Otherwise I think we would be left with an expired primary certificate forever - that doesn't make much sense?!
Hope someone can shed some light on this.
/Chris
There are two certificate slots so you can always have at least one valid, working certificate. If you would have only one certificate and it would expire or be deleted, the cluster would not work.
Yes, Service Fabric cluster will automatically use the declared certificate with a further into the future expiration date; when more than one validate certificate is installed on the host. This doesn't make it the primary certificate, this rule also applies to the secondary certificate. If you select a certificate by its common name, multiple results may be found, and this is they way one is selected.
The process is like this:
upload a new secondary certificate
enable auto-rollover
delete the primary certificate after the auto rollover has completed
more info here.
Related
We're operating Eclipse Hono and would like to perform zero-downtime updates on all components in our cluster.
For authentication between the different Eclipse Hono components we use the Hono Auth Service.
There we configured a shared secret (HONO_AUTH_SVC_SIGNING_SHARED_SECRET) to be used to for signing the issued tokens.
Consuming services (e.g. Command Router / Mongo DB Device Regsitry) are configured with the same secret.
When changing the shared secret we simultaneously need to restart all instances of the mentioned microservices, which leads to a short downtime.
If we would perform a rolling update, the old instances would not validate the issued tokens of instances already running with the new shared secret.
Has anyone the same issue, or knows how to perform a zero-downtime update?
One option to solve our problem would be the possibility to configure next to the HONO_AUTH_VALIDATION_SHARED_SECRET another secret (HONO_AUTH_VALIDATION_SHARED_SECRET_FALLBACK) which would be tried if the primary fails.
Like this we could perform a rolling update of all components without downtime.
The usage of a certificate instead of the shared secret has as far as I can see the same restriction.
Thanks
Chris
I also do not see any option to cycle the shared secret based on the current implementation without incurring any downtime.
For this to work, Hono's components would need to support configuration of multiple shared secrets for validation of the tokens, as you correctly pointed out. Maybe you want to open an issue for this with Hono?
Azure Key Vault has an option to auto-renew certificate within x days before expiry. I need to auto-renew cert in Azure Key Vault x days from creation.
As shown in the image below, there is no option in portal to do so.
One way would be to leverage "Automatically renew at a given percentage lifetime". For that I would either need to understand lifetime of each certificate in Key Vault or set lifetime of each cert in Key Vault to be same to avoid confusion of setting how much percentage lifetime for which certificate.
Any suggestions on how to achieve it via some tool or scripts? Looking for a cleaner way than the one mentioned above.
You could calculate the expiration you should use along with the percentage of lifetime, but if you want more explicit control over when the certificates are renewed, perhaps consider a scheduled trigger with an Azure Function app or an Azure Automation runbook.
The Disable-AzureRmVMDiskEncryption cmdlet (I believe disable = decryption) just needs a name of the VM to disable encryption.
Isn't it a security issue disabling encryption without any key ? How can the disks be safeguarded from disabling encryption, through RBAC ?
Isn't it a security issue disabling encryption without any key ?
It doesn't look like a security concern because there are two separate concerns at play here:
Protecting Data at rest - which is taken care of by Azure Disk Encryption (only if you enable it as per Azure Data Security and Encryption Best Practices)
Protecting access to VM itself and it's resources - which is taken care of by RBAC.
When you Disable Disk Encryption
It does actually make sure that currently encrypted data gets decrypted back and is no longer encrypted at rest.
Since Azure already knows the details about the Key Encryption Key (KEK) and Disk Encryption Key (DEK) details from the time you enable the encryption in first place, it doesn't really need to ask back for these details in order to decrypt the currently encrypted information.
Here are the details of decryption flow from Microsoft Docs:
Decryption workflow
How can the disks be safeguarded from disabling encryption, through
RBAC ?
The real concern of who can manage VM in general or initiate/disable Disk Encryption can be controlled by assigning (or removing) the correct roles like Owner or Virtual Machine Contributor using RBAC from Azure Portal/PowerShell etc.
The subject says it all...
Why there are two keys for Azure DocumentDB (primary and secondary)?
This is so that you can expire a key without having any system downtime. Say you want to replace your primary key. The procedure is
Configure your service to use the secondary key - if you use the service config you can do this without downtime.
Regenerate the primary key
(Optional) reconfigure your service to use the new primary key
If there was only one key at a time, your service would be down while you did the key replacement.
Good practise is to replace your keys on a regular basis (e.g every 6 months or whatever is appropriate based on the sensitivity of your data). You should also replace keys when anyone who has access to the keys leaves your business or team. Finally, you should obviously replace them if you think they have been compromised in some way. E.g. accidentally written to a log or posted to a public GitHub repo - it happens...
https://securosis.com/blog/my-500-cloud-security-screwup
Both the primary and secondary keys can be regenerated in the Azure portal (note: at the time of writing this is the preview portal). Select your DocumentDB then the Keys pane. There are two buttons at the top of the pane:
From the Azure Portal, on the Configure Tab for a notification hub I am able to generate a primary key and secondary key. I understand these are required to gain programmatic access to the Azure API - allowing my client app to create registrations and send messages.
Could anyone please explain:
Why are there two keys (primary and secondary)?
Do the keys generated from this UI expire and if so how long do they live before expiry?
They don't expire. The reason there are two is because it's recommended that you regenerate the keys periodically for security reasons. For example, suppose your application is using the primary key today. If you regenerated the primary key, then your application would be broken until you could update it and resulting in downtime. Instead, you can change your application to use the secondary key with basically little or no downtime. Then, after your application has been updated, you can regenerate the primary key. Next month (or whatever schedule you like), you can repeat the process, switching back to the primary key and regenerating the secondary key.
This is not unique to Notification Hubs. You will see primary and secondary keys in other services such as Storage and Media Services. The idea is the same.