You have written a Kubernetes application that leverages Pod Security Policies that is deployed to customers' sites. Please answer the following questions:

● How would you work on phasing Pod Security Policies out of your application?

If I know a security expert who's familiar with the situation, I would ask them for advice. Then, I would start by looking for the points of dependency in my application code and make sure that I have good test coverage around them before touching anything.

I would try to determine whether a piecewise phaseout was possible or if a replacement of PSP's functionality needed to be done all at once. I might find that the phaseout work could be distributed across devs and sprints. I would talk to the team about what I'm seeing and thinking. If better encapsulation of the dependency is possible, I would set that as a refactoring goal.

I would add new tests where a need was anticipated and would work toward implementing the minimum changes possible. I would progressively add to and refactor the codebase, until completing the solution. I would be focused on providing opportunities to discover mistakes in my assumptions about what's required and correct for them before releasing the phased-out version.

● How would you ensure deployments of your application can transition away from Pod Security Policies while maintaining an effective security approach?

I would use the release notes to announce when a security update was part of the latest release. If I could maintain backwards compatibility, I would do that -- for as long as it's reasonable. If I could issue a deprecation warning from my application, when the user upgrades or uses the app, I would do that too. My goals would be:

1. making sure that I release a well-tested, well-understood solution when the time comes
2. making users aware that they should upgrade to maintain security
3. offering users a link to instructions on any steps they need to take

● How would you evaluate whether or not to adopt a replacement to Pod Security Policies?

I would start by following the discussion and seeing what options the Kubernetes team suggests. I can see in the Kubernetes docs a recommendation to migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller. I see in PGO's internal/initialize/security.go file that this is underway. I would investigate whether there was any loss of functionality that I require, which seems like a possibility, given that one of the complaints about PSP sounded like it just kept growing -- maybe they removed something I need. If I needed to bring in an external dependency, I would make sure that it came from a live, popular, and secure repository with an acceptable license. And, I would experiment with that dependency and browse its code to make sure it didn't have an appreciable impact on my application's footprint or just bring in more code than what was required to get the job done. It might be better to roll my own.

● What strategies would you use for working with a Kubernetes API that could be removed in a future release?

I would try to move all calls to that API into a single package, and wrap them up in functions that conceal as many details from the consumer as possible. Even if I'm leaking types from the Kubernetes dependency, at least I've created visibility into where and how I'm using that API. When I need to remove those calls, package-level encapsulation will prevent shotgun surgery.

SEE: https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/
SEE: https://github.com/CrunchyData/postgres-operator/commits/master/internal/initialize/security.go