-
Notifications
You must be signed in to change notification settings - Fork 1k
Set user and group in security context #1083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi, is there any chance to get this merged or will there be another way to run the container without root privileges, besides building a custom image? |
initContainers, | ||
sidecarContainers, | ||
&tolerationSpec, | ||
effectiveRunAsUser, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern is here, this seems to set runAsUser and runAsGroup to the new 101/103 combination by default.
I will have to understand what this was/is before.
var err error | ||
var spec acidv1.PostgresSpec | ||
var cluster *Cluster | ||
var spiloRunAsUser = int64(101) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above, while for users with the spec.fsGroup set this may be or have been the default for everyone not using fsGroup spec this seems to change the default from former root(0) to 101 uid.
Hi @Jan-M, thanks for the review. I think the default will still be, that the container runs as root, but maybe I missed something in my tests. I used the Test 1: Apply the default ManifestapiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: acid-minimal-cluster
namespace: default
spec:
teamId: "acid"
volume:
size: 1Gi
numberOfInstances: 1
users:
zalando: # database owner
- superuser
- createdb
foo_user: [] # role for application foo
databases:
foo: zalando # dbname: owner
preparedDatabases:
bar: {}
postgresql:
version: "12" Postgres Container
Test 2: Apply the ManifestapiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: acid-minimal-cluster
namespace: default
spec:
teamId: "acid"
volume:
size: 1Gi
numberOfInstances: 1
spiloFSGroup: 103
users:
zalando: # database owner
- superuser
- createdb
foo_user: [] # role for application foo
databases:
foo: zalando # dbname: owner
preparedDatabases:
bar: {}
postgresql:
version: "12" Postgres Container
Test 3: Apply the ManifestapiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: acid-minimal-cluster
namespace: default
spec:
teamId: "acid"
volume:
size: 1Gi
numberOfInstances: 1
spiloRunAsUser: 101
spiloRunAsGroup: 103
spiloFSGroup: 103
users:
zalando: # database owner
- superuser
- createdb
foo_user: [] # role for application foo
databases:
foo: zalando # dbname: owner
preparedDatabases:
bar: {}
postgresql:
version: "12" Postgres Container
|
You are right, looks good to me. I got confused by the test case in there, fiddling with the default. |
👍 |
@ricoberger Thanks for the detailed answer showing the different configurations and the output. |
👍 |
thank you for the contribution, @ricoberger |
Since version 1.6-p3 of the Spilo image it is possible to run the processes inside the container without root privileges. This PR introduces two new options, so a user can run the container without root and without the need to build a custom image.
The two new options for the security context, can be set via ConfigMap or the CR:
spiloRunAsUser
/spilo_runasuser
: Set the user ID in the security contextspiloRunAsGroup
/spilo_runasGroup
: Set the group ID in the security contextThis PR addresses #1052.