A Fine Slice Of SQL Server
SQL Server provides two different forms of authenticating the users that connect to the database server: Windows Authentication, which is the default and preferred method, and SQL Server Authentication, which needs to be explicitly enabled.
There are reasons you might need to enable SQL Server authentication and, although advertised as less secure than Windows Authentication, there are still a few things we can do to minimise the risks.
Read on for those tips.
Comments closedAndrew Pruski didn’t want to type that much:
The post goes through deploying a Helm Chart to Kubernetes and then running the following to decode the secrets that Helm creates in order for it to be able to rollback a release: –
kubectl get secret sh.helm.release.v1.testchart.v1 -o jsonpath="{ .data.release }" | base64 -d | base64 -d | gunzip -c | jq '.chart.templates[].data' | tr -d '"' | base64 -dBut that’s a bit long winded eh? I don’t really fancy typing that every time I want to have a look at those secrets. So I’ve created a kubectl plugin that’ll do it for us!
Click through to see the code, how you install the plugin, and how you use it.
Comments closedEitan Blumin doesn’t like the SSRS authentication prompt:
In this post, I hope to summarize the various methods that we have, in order to get rid of that annoying authentication prompt. Each method has its own advantages and disadvantages in terms of complexity of implementation, versatility, and the level of security that it provides. More specifically: the more secure and versatile a method is – the more complicated it is to implement.
Read on for four such techniques, as well as a bonus technique.
Comments closedRishit Mishra walks us through Azure Key Vault:
As the name suggests, Azure Key Vault is used to store and manage keys securely. Key Vault can be used to store the cryptographic secrets and keys such as authentication keys, storage account keys, data encryption keys, passwords and certificates.
Azure Key Vault enables developers to create the keys for development and testing in minutes, and they can further migrate this setup seamlessly onto the production environment.
The centralized key store/vault can be securely managed by the Key Vault owner who manages permissions to this key store and would be responsible for keeping the secrets secure.
Key Vault becomes quite useful in managing secrets in tools like Azure Databricks and Azure Data Factory without saving a bunch of keys in configuration files. And it’s a lot safer than that option, too.
Comments closedBernardo Lares walks us through some good practices around managing credentials and secrets in R:
I have several functions that live in my public lares library that use
get_creds()to fetch my secrets. Some of them are used as credentials to query databases, send emails with API services such as Mailgun, ping notifications using Slack‘s webhook, interacting with Google Sheets programatically, fetching Facebook and Twitter’s API stuff, Typeform, Github, Hubspot… I even have a portfolio performance report for my personal investments. If you check the code underneath, you won’t find credentials written anywhere but the code will actually work (for me and for anyone that uses the library). So, how can we accomplish this?
Read on to learn how.
Comments closedGavin Campbell shows how you can pull secrets out of an Azure DevOps Pipeline:
For secrets created in the Azure DevOps UI, whether pipeline-scoped or in a variable group, it is not so simple to retrieve the variables after creation. This might be required for a number of reasons, most often troubleshooting. The need to do this is often an indicator that the project should have been using an Azure Key Vault in the first place.
Previously it was necessary to jump through some hoops to access secret variables, but it turns out this is no longer required. It also appears the recommended approach of mapping secrets to environment variables is currently not working for secret variables from variable groups.
I second the notion of using Key Vault for secrets management.
Comments closedDavid Millman shows off the Privitar Kafka Connector:
The initial message structure, in the left column above, is a simple JSON document with five fields. The middle column contains the list of rules that must be applied, defining the policy. On the right is a sample output message generated as a result of the policy being applied to the initial message.
In the Privitar Policy Manager, a user maps the individual fields to the appropriate rule, as shown in the screenshot below. A rule is applied to each of the fields and the schema is read as a single table structure, named
testfile. These rules can be applied for every instance of the schema.
Read on for more.
Comments closedRob Sewell is happy to stop using Import-Clixml:
I love notebooks and to show some people who had asked about storing secrets, I have created some. So, because I am
efficientlazy I have embedded them here for you to see. You can find them in my Jupyter Notebook repository
Rob has a follow-up on the topic:
Following on from my last post about the Secret Management module. I was asked another question.
> Can I use this to run applications as my admin account?
A user with a beard
Well, Rob has a notebook for that.
1 CommentAdam Youngberg relates an experience with securing public S3 buckets:
As a response to our initial alert, we took action to identify all of our S3 buckets and the public / non-public status. Since Databricks is a cloud-native company, we had already deployed JupiterOne, a commercial cloud asset management solution that allowed us to quickly query and determine which assets were public. Open-source tools are available, such as Cartography from Lyft, which allow for similar query capabilities. With the outputs of our queries, we were able to quickly identify and triage our public buckets and determine whether they should remain public.
Read on for the process, as well as some issues they experienced in rollout.
Comments closedGerhard Brueckl shows how we can get around a limitation in the Azure Data Factory user interface:
As You can see, the setting “AccessToken” can use a Key Vault reference whereas settings like “Databricks Workspace URL” and “Cluster” do not support them. This is usually fine because the guys at Microsoft also thought about this and support Key Vault references for the settings that are actually security relevant or sensitive. Also, providing the option to use Key Vault references everywhere would flood the GUI. So this is just fine.
But there can be good reasons where you want to get values from the Key Vault also for non-sensitive settings, especially when it comes to CI/CD and multiple environments. From my experience, when you implement a bigger ADF project, you will probably have a Key Vault for your sensitive settings and all other values are provided during the deployment via ARM parameters.
So you will end up with a mix of Key Vault references and ARM template parameters which very likely will be derived from the Key Vault at some point anyway. To solve this, you can modify the JSON of an ADF linked service directly and inject KeyVault references into almost every property!
Click through to see how that works, as well as the ramifications.
Comments closed