Re: Custom SCC assigned to wrong pods

[Vyacheslav Semushin]

2018-06-20 8:22 GMT+02:00 Daniel Comnea :

> Thanks Slava for reply.
>
> For everyone benefit (in case others come across the same issue) it was
> all down to my custom scc *priority* which was *null*. Once i set it to a
> value higher than 0 ( default 'restricted' scc has 0) then everything
> works as expected.
>

If it's possible, it's better to modify a pod manifest to explicitly
request everything that it expects to have. If your custom SCC was beaten
by the "restricted" SCC, it means that for the system these SCCs were
recognized as covering everything a pod needs to have. If a pod needs
something that the "restricted" SCC doesn't provide, this pod should
request for it and "restricted" SCC won't be selected at all because it
doesn't fulfill the request.

While an approach with priority field works, it could stop working when a
user will be granted access to yet another SCC with a higher priority (for
example, "anyuid").

HTH

-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Custom SCC assigned to wrong pods

[Vyacheslav Semushin]

2018-06-19 10:31 GMT+02:00 Daniel Comnea :

>
>
> On Mon, Jun 18, 2018 at 11:19 PM, Jordan Liggitt 
> wrote:
>
>> Redeploying the application creates new pods.
>>
>> Since you removed the part of your custom scc that allowed it to apply to
>> your pods, those new pods were once again subject to the restricted policy.
>>
> [DC]: that was not removed, it was added in step 2) and never removed
> however during step 4) (open shift upgrade) something happened which made
> the new pods subject to default restricted policy.
>

If "pods started to crash", it means that they were re-created (or new ones
were added).

Could you show us a pod definition (oc get pod  -o yaml?


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Web Console - 3.9 - Pod / CrashLoopBackOff

[Vyacheslav Semushin]

2018-05-17 15:15 GMT+02:00 Sam Padgett :

> The file mode is 400, and I think anyuid breaks reading it since the user
> changes.
>
> https://github.com/openshift/openshift-ansible/blob/master/
> roles/openshift_web_console/files/console-template.yaml#L90
>
> The console doesn't need anyuid... I'm not sure what's adding it.
>

Thinking a bit more about this, I can say, that webconsole can be improved.
While it doesn't need root privileges it still needs a "stable" UID and it
doesn't expect that this UID can be changed.

Would it be possible to, follow our own recommendations, and use 040 mode
instead? Using group will give us more predictable results, because all
pods always have root group.

-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Web Console - 3.9 - Pod / CrashLoopBackOff

[Vyacheslav Semushin]

I'd like to continue this discussion because this broken configuration
could be easily reproduced by following our own documentation:

https://docs.openshift.org/latest/admin_guide/manage_scc.html#enable-images-to-run-with-user-in-the-dockerfile
How we can fix this?

Do we have a virtual group (like system:authenticated) that doesn't include
any system-related users? In this case, we will be able to use such a group
in the example above.


2018-05-17 15:15 GMT+02:00 Sam Padgett :

> The file mode is 400, and I think anyuid breaks reading it since the user
> changes.
>
> https://github.com/openshift/openshift-ansible/blob/master/
> roles/openshift_web_console/files/console-template.yaml#L90
>
> The console doesn't need anyuid... I'm not sure what's adding it.
>
> Sam
>
> On Thu, May 17, 2018 at 9:03 AM, Clayton Coleman 
> wrote:
>
>> anyuid is less restrictive than restricted, unless you customized
>> restricted.  Did youvustomize restricted?
>>
>> On May 17, 2018, at 8:56 AM, Charles Moulliard 
>> wrote:
>>
>> Hi,
>>
>> If we scale down/up the Replication Set of the OpenShift Web Console,
>> then the new pod created will crash and report
>>
>> "Error: unable to load server certificate: open
>> /var/serving-cert/tls.crt: permission denied"
>>
>> This problem comes from the fact that when the pod is recreated, then the
>> scc annotation is set to anyuid instead of restricted and then the pod
>> can't access the cert
>>
>> apiVersion: v1
>> kind: Pod
>> metadata:
>>   annotations:
>> openshift.io/scc: anyuid
>>
>> Is this bug been fixed for openshift 3.9 ? Is there a workaround to
>> resolve it otherwise we can't access anymore the Web Console ?
>>
>>
-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Any alternative to "oc adm policy add-scc-to-user" ?

[Vyacheslav Semushin]

2018-05-25 10:23 GMT+02:00 Daniel Comnea :

> Slava,
>
> spot on !!!
>
> I don't know why i was under the impression that in 3.7 RBAC been fully
> implemented and everything on parity, guess i was wrong.
>

One doesn't exclude another: RBAC was fully implemented and replaced our
previous mechanisms. But based on my understanding, RBAC is mostly about
authentication/authorization so it has low relation with SCC. Also because
SCC is our own API we didn't implement such integration before.


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Any alternative to "oc adm policy add-scc-to-user" ?

[Vyacheslav Semushin]

2018-05-24 23:16 GMT+02:00 Daniel Comnea :

> Hi,
>
> Is any alternative to "oc adm policy add-scc-to-user" command in the same
> way there is one for "oc create serviceaccount foo" which can be achieved
> by
>
> apiVersion: v1
>
> kind: ServiceAccount
>
> metadata:
>
>   name: foo-sa
>
>   namespace: foo
>
>
> I'd like to be able to put all the info in a file rather than run oc cmd
> sequentially.
>

No, there was no alternative except editing SCC via oc edit/oc patch/etc.

Since 3.10 it became possible to use ClusterRole and ClusterRoleBindings
for such things. See related PR for details:
https://github.com/openshift/origin/pull/19349 It also has a link to a
Trello card that contains a few pointers.


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Web Console - 3.9 - Pod / CrashLoopBackOff

[Vyacheslav Semushin]

2018-05-24 10:10 GMT+02:00 Charles Moulliard :

> +1 to document somewhere how SCC is working, priority defined,  and
> what should be done to resolve such issues
>

Perhaps this info is hard to find but it's there:
https://docs.openshift.org/latest/architecture/additional_concepts/authorization.html#scc-prioritization


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Web Console - 3.9 - Pod / CrashLoopBackOff

[Vyacheslav Semushin]

2018-05-23 23:06 GMT+02:00 Daniel Comnea <comnea.d...@gmail.com>:

>
>
> On Wed, May 23, 2018 at 5:20 PM, Vyacheslav Semushin <vsemu...@redhat.com>
> wrote:
>
>> 2018-05-17 17:18 GMT+02:00 Charles Moulliard <cmoul...@redhat.com>:
>>
>>> The trick / solution  described there doesn t work. I tried also using
>>> the ansible playbook of Openshift to remove the project and recreate it and
>>> the pod is always recreated with Openshift annotation = anyuid
>>>
>>
>> The reason of why "anyuid" SCC is being applied is because it was granted
>> to all authenticated users. And because anyuid has priority 10, it gets
>> applied instead of "restricted" SCC.
>>
> [DC]: how do you know about anyuid and priority 10?
>

In the gist that you provided, you posted the output of the oc get
scc/anyuid -o yaml command that shows me that SCC has been granted to
system:authenticated group and
system:serviceaccount:openshift-web-console:webconsole user. Also it shows
the priority field.


> In other words how can i find out each scc what priority has ?
>

Both of the following commands contain PRIORIT field:
oc get scc
oc get scc 


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Web Console - 3.9 - Pod / CrashLoopBackOff

[Vyacheslav Semushin]

2018-05-17 17:18 GMT+02:00 Charles Moulliard :

> The trick / solution  described there doesn t work. I tried also using the
> ansible playbook of Openshift to remove the project and recreate it and the
> pod is always recreated with Openshift annotation = anyuid
>

The reason of why "anyuid" SCC is being applied is because it was granted
to all authenticated users. And because anyuid has priority 10, it gets
applied instead of "restricted" SCC.


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: CAP_LINUX_IMMUTABLE

[Vyacheslav Semushin]

2018-03-28 19:17 GMT+02:00 Srinivas Naga Kotaru (skotaru) :

>
> Is it possible to use CAP_LINUX_IMMUTABLE security context with restricted
> SCC? One of our client want to use chattr +a /tmp/logs/*.log command in
> pod. We don’t want to relax or give privileged SCC for any clients.
>

The "restricted" SCC doesn't allow any extra capabilities except those that
are granted by default by Docker. So, the answer is "No, you can't".

If you "don’t want to relax or give privileged SCC", you still may create a
custom SCC that will be identical to "restricted" but also allows
CAP_LINUX_IMMUTABLE
capability. Such SCC can be granted only to some clients, so they will be
able to use it.

Hope this helps!

-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: environment variables when running multiple containers in one pod

[Vyacheslav Semushin]

2017-11-27 10:34 GMT+01:00 Yu Wei :

> Hi，
>
> When running mysql with other containers within one pod, it seemed that
> environment variable "MYSQL_ROOT_PASSWORD" didn't work as expected.
>
> Password set in "MYSQL_ROOT_PASSWORD" couldn't be used for connecting to
> mysql.
>

It doesn't work only when other containers are being created and when they
try to connect to mysql container? If yes, then it could be a race when
mysql container isn't ready while others try to connect to it.


-- 
Slava Semushin | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev