Voice of the DBA

Author: way0utwest

  • Learning Kubernetes Security Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Here I continue on with a few videos on secrets, configuration management and RBAC.

    Secrets

    I am glad that the idea of storing data securely has come to so many applications. Authentication, authorization, privileges, and more are complex and hard to get right. We continually see problems with passwords, certificates, and the link not being managed well.

    Kubernetes has the concept of secrets, which can be values or file contents (like a certificates). These can then be sent or mounted to containers for use.

    One problem, these are stored in the Kubernetes etcd (keyvalue store) in an unencrypted format. Kubernetes has new concepts to integrate into key management areas, like Azure Key Vault, to protect secrets, though Kubernetes privilege controls are still needed.

    A gross simplification, but I learned a little more about what secrets are.

    Configuration Management

    This is interesting to me, because I like abstracting things away. In Kubernetes, we abstract a configuration object as a separate entity, which can then be applied to a container/pod later. This also works through deployments, allowing configurations to be part of the rolling deployment, which can prevent issues.

    If you have good testing/evaluation of what is healthy. This is likely easier than comprehensive unit testing, but still.

    A good idea, just not sure if this is too much.

    RBAC

    I always think of this as row-based, but it’s really role-based, so maybe that should be the way I translate RBAC in my head.

    Like most systems that use RBAC, there is, of course, a role. The video wanders a bit in the explanation, but I’ll try to summarize what I learned. There are two facets to roles. First, these are verb/noun pairs that determine what permission is available for what resource. Like get/list for the verb, and pod, volume, service, etc. for the noun. These are setting up the permission side.

    However, there is another facet. These roles can be set as cluster roles, similar to server roles for SQL Server, or at the namespace level, more like a database role. In either case, you are scoping permissions. Obviously, be careful with cluster roles.

    The other side of this is the user. We can have users or groups used for these roles, similar to what is in SQL Server.

    A simple explanation, but at least I have some idea of the concept.

  • Getting Downtime

    It’s been a crazy year, as are many of my years. I tend to like that, because I prefer to be busy rather than idle. That’s good, but I am aware of the dangers of doing too much, especially across time.

    Most of my travel comes from May-October, and I’ve had a lot this year. In that time frame, I’ve had 4 international trips already, with 2 more to come. To help deal with that, I know I need some breaks between trips.

    Last week I was in the UK for work, but I knew that I would get a little break this week. You might have seen that I’ve republished a few editorials as I was in Custer, S.D. this week. It’s a camping week with the family, and a chance for me to unwind with no real connectivity or responsibilities. A good break for me after a bit of travel.

    I decided to take off August this year from travel. I’m sad to be missing a few events (Louisville, Baton Rouge among them), but I need the downtime. I also take my daughter to university in  a couple weeks, so I’ve got a long weekend helping her move in and then touring New York state a bit with my wife.

    Like lots of IT people, I struggle to get away from work at times, so I’m making an effort to get better. You should as well.

  • The Problem with Users

    I think Troy Hunt is an incredible thinker. His view and work to improve security in infrastructure and applications is incredible and valuable. I think the focus on better passwords and the implications of data breaches has grown in the world, perhaps due to Troy’s work with https://haveibeenpwned.com/. Plenty of non technical people know about the site, and more than a few government officials.

    Recently I read a piece from Mr. Hunt on passwords and why they will continue to exist for some time. I agree that the understanding and convenience of passwords makes them a tool that will remain widely deployed for some time. I like the additional verification from Google and other sites with a text or message on a phone for MFA (multi-factor authentication), and would love to see that in SQL Server, but this doesn’t eliminate the need for passwords. It just adds to them.

    The idea of password has a parallel in database development as well. One of the most basic things that we do as data professionals is fix problems on our systems. We do this in various ways, but I’d bet almost every organization has an individual that has made a change in a live, production database. Why? Because it’s easy and it needs to be done sometimes to fix code, data, or something else quickly. We know it’s not ideal, but it works.

    I try to talk about compliant Database DevOps, about having a process, the need for evaluating code and data changes, about limiting access to production, about ensuring every statement is tested elsewhere, about even masking/anonymizing/generating data in dev/test environments. Most of us know these are good ideas, and likely quite a few of us would like to adopt them. Why don’t we? Part of it is the ease with which we get things done. Another part is the success that we have with our current process.

    We fix things, we add indexes, we correct typos in code, we adjust our deployment to succeed, even though the scripts had problems. We roll forward constantly, coding by the seat of our pants, and for the most part our organizations continue to function well. Brent Ozar’s recent survey on production data in development shows that in some cases there isn’t a security risk, but quite a few times expediency and troubleshooting mean we work in production or copy data.

    I still think DevOps is the better way to move development forward. At Redgate, we have a suite of tools that help you smooth database development to reduce mistakes and problems. Not because you can’t be successful the way you are, but because you can go faster, make more experiments and changes, and deploy on demand rather than as a special event. We help you save time, which should translate into your highly paid staff spending time on creative new solutions, not fixing tedious problems. We even expect you’ll do things in production, which is why DLM Dashboard was built.

    We’re not the only vendor doing this. Plenty of others are trying to help you build a smoother database DevOps process, including Microsoft. Most expert software developers know that DevOps is a better way to build software that focuses and takes advantage of the creativity of your developers, while reducing the time spent on non-creative work. I, and many others, feel that the database needs to be a part of this to be as successful as we can be.

  • Copy Files to a Docker Container

    One of the things that’s handy when working with containers is being able to move files in and out of the container. Certainly you can do this from a network share or other similar mechanism, but what about a straight copy?

    Docker has a command with the cp parameter to do this.

    docker cp WideWorldImporters.bak SQL17:/var/opt/mssql/data/WideWorldImporteres.bak

    The structure is the from:to, separated by a space as two parameters. If you’re going to the host, then just the path and filename, or just name if the current folder) for the file. For the container, you need the container ID or name with a colon (:) and then the relative path.

    A quick way to begin changing and customizing your containers by moving data in and out as needed.