Set up Resilient Secrets

Does this work in the other direction as well? Replicating from on-prem to the cloud?

Yes, it should. You would just configure SSC as the replica. Typically it’s the other way around because companies are trying to avoid having to configure and manage complex on-premises environments.

Yes, per our sales engineers it works either way.

Cloud to On-prem
On-prem to Cloud
On-prem to other On-prem
Cloud to Cloud

And any other combination

​@brigid.colver we are on prem secret server and we recently started an engagement to setup resilient secrets but are being told it is only  sync’ed via CLOUD - to - ON-prem 
Confused! What’s the right answer!?!? 

I believe Brigid’s previous answer is correct, it can sync any direction - however from my experience there are actually different licensing SKUs for the different types, so the license you have may dictate that.

Thanks ​@andrew.leckie , 

I’m being told that the sync initiates from the Cloud into my SS internal server. This methodology of connectivity is prohibited in our environment (direct connection from external to internal server). 

We’d prefer sync to initiate from our internal to the Cloud but again, unsure if this is supported. 

You are correct, it is a pull not a push. So, if your DR replica is SSC, it would be pulling from your on-premises SS tenant. With that being said, the main reason Delinea created the DR replica was because of feedback from their SSC customers, concerned with not being able to access SSC in specific scenarios (outside of Delinea’ s control). That is why it is a pull not a push, as it was initially intended to sync from SSC to on-prem. This is the same way Distributes Engines work in SSC, pulling (outbound traffic) not pushing (inbound traffic). It is a bit unconventional to have your DR replica as SSC since there are greater risks with properly securing SSC vs on-prem, because of it being internet facing.

Your policies to prevent direct connection from external to internal are good. Even though it is possible to use SSC as your DR replica, I wouldn't recommend doing it. However, if you planned on migrating from on-prem to SSC, it would be a good one-time exception to your internal policy and a quicker way to do a lift-and-shift style migration.

Hi there,

As Javan indicated, the Resilient Secrets replica is pulling from the source instance. With the information provided, you would be unable to have the sync initiate from your internal replica.

Since this is understandably prohibited within your environment, what are you currently doing with your on-prem deployment to ensure resiliency (aside from pursuing this option)? Are you able to leverage things such as global load balancers and SQL Always On Availability Groups (AGs)? The successful addition of both of these sets you up for a significantly resilient deployment in most cases.

We have several architecture examples that you can review on our docs page found here. Take a look at those and feel free to ask any additional questions you might have.

Hey ​@Austin H. thanks, 

We have SQL Always On and are spread across two data centers with the web and SQL servers.