If you are using Kubernetes, you have a myriad of settings you can tweak under the securityContext of your
Deployment. Here is a sample
apiVersion: v1 kind: Pod metadata: name: my-asp-app spec: securityContext: runAsUser: 1000 fsGroup: 2000 containers: - name: my-asp-app image: my-asp-app:1.0.0 env: - name: COMPlus_EnableDiagnostics value: 0 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: add: ["NET_ADMIN", "SYS_TIME"]
allowPrivilegeEscalation setting stops users who manage to get into your container from escalating their privileges to become a super user. I'm not sure why any container should need this enabled. Setting this to false should be the default but it isn't, you make sure to set this yourself. This is another case of an insecure default.
In my last post in the series, I already discussed how to enable a read-only file system in your Docker container. I've already set
COMPlus_EnableDiagnostics to zero using an environment variable and the
readOnlyRootFilesystem is set to true to enable this feature.
fsGroup settings ensure that the user and group of the user running the app is not the root user. Some Docker images I have seen do this for you and bake these settings into the Docker image while others require you to manually specify another user as above. I raised an issue...
capabilities...blah blah blah