Re: Custom SCC assigned to wrong pods

[Jordan Liggitt]

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.

On Jun 18, 2018, at 6:12 PM, Daniel Comnea  wrote:

Hi Jordan,

Reviving the thread on the custom scc with another question if you don't
mind:

After i removed the

groups:
- system:authenticated

from my custom scc i went ahead and done the following:

1) Created Foo project
2) Created my custom scc (which i shared in my previous email)
3) Deployed the app pods
4) Upgraded Openshift to 3.6.1 – pods started to crash due to having the
default restricted scc instead of the custom scc previously assigned.

The docs says very clear that only the default scc will be reset to initial
state and so i was expecting the POD to pick up the custom scc even if they
get bounced during upgrade.

Any thoughts ?

Thanks !

On Wed, May 23, 2018 at 11:18 PM, Daniel Comnea 
wrote:

> I see the rational, thank you for quick response and knowledge.
>
> On Wed, May 23, 2018 at 10:59 PM, Jordan Liggitt 
> wrote:
>
>> By making your SCC available to all authenticated users, it gets added to
>> the set considered for every pod run by every service account:
>>
>> users:
>> - system:serviceaccount:foo:foo-sa
>> groups:
>> - system:authenticated
>>
>>
>> If you want to limit it to just your foo-sa service account, you should
>> remove the system:authenticated group from the SCC
>>
>>
>>
>> On Wed, May 23, 2018 at 5:54 PM, Daniel Comnea 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm running Origin 3.7.0 and i've created a custom SCC [1] which is
>>> being referenced by different Deployments objects using
>>> serviceAccountName: foo-scc-restricted.
>>>
>>> Now the odd thing which i cannot explain is why glusterFS pods [2]
>>> which doesn't reference the new created serviceAccountName [3] do have
>>> the new custom scc being used [4]...is that normal or is a bug?
>>>
>>>
>>>
>>> Cheers,
>>> Dani
>>>
>>> [1] https://gist.github.com/DanyC97/56070e3f1523e31c1ad96980df6d7fe5
>>> [2] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e0918
>>> [3] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e
>>> 0918#file-glusterfs-deployment-yml-L65
>>> [4] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e
>>> 0918#file-glusterfs-deployment-yml-L11
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Custom SCC assigned to wrong pods

[Jordan Liggitt]

By making your SCC available to all authenticated users, it gets added to
the set considered for every pod run by every service account:

users:
- system:serviceaccount:foo:foo-sa
groups:
- system:authenticated


If you want to limit it to just your foo-sa service account, you should
remove the system:authenticated group from the SCC



On Wed, May 23, 2018 at 5:54 PM, Daniel Comnea 
wrote:

> Hi,
>
> I'm running Origin 3.7.0 and i've created a custom SCC [1] which is being
> referenced by different Deployments objects using serviceAccountName: foo-
> scc-restricted.
>
> Now the odd thing which i cannot explain is why glusterFS pods [2] which
> doesn't reference the new created serviceAccountName [3] do have the new
> custom scc being used [4]...is that normal or is a bug?
>
>
>
> Cheers,
> Dani
>
> [1] https://gist.github.com/DanyC97/56070e3f1523e31c1ad96980df6d7fe5
> [2] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e0918
> [3] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e0918#file-
> glusterfs-deployment-yml-L65
> [4] https://gist.github.com/DanyC97/6b7a15ed8de87951cee6d038646e0918#file-
> glusterfs-deployment-yml-L11
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: SCC privileged not applying

[Jordan Liggitt]

> On Dec 19, 2017, at 1:49 AM, Weiwei Jiang  wrote:
>
> But the scc is trying to verify the creater account(you can see this with 
> audit enabled), and should be daemonset-controller or something like this but 
> not the given serviceaccount).

That's not accurate. You can give the SCC permissions to either the
creating user (in the case of a daemonset, this is the daemonset
controller) and/or to the service account of this pod.

You should avoid giving SCC permissions to the pod creating
controllers, since that enables any user that can create a daemonset
to make use of those permissions via the controller.

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: add role for LDAP user with short name

[Jordan Liggitt]

You likely want to specify sAMAccountName as the preferred username
attribute. Note that this would only apply to new users. Existing users
would retain their long username.



On Sep 18, 2017, at 11:07 PM, Tran Tien Dung  wrote:

Hi everyone,
I user LDAP to login openshift, when I want to add role to ldap user on
project, I have to use a full DN like "CN=Dung Tran Tien,OU=Ict
Team,OU=Users,OU=AAVN_HCM,DC=aavn,DC=local" ,please see the result of
command " oc get user --o json"  and below


It does not show a short name

is there any thing I need to do in LDAP configuration? here is my config

>  identityProviders:
>
>   - name: "Active_Directory"
>
> challenge: true
>
> login: true
>
> provider:
>
>   apiVersion: v1
>
>   kind: LDAPPasswordIdentityProvider
>
>   attributes:
>
> id:
>
> - dn
>
> email:
>
> - mail
>
> name:
>
> - cn
>
> preferredUsername:
>
> - uid
>
>   bindDN: "cn=u1,dc=aavn,dc=local"
>
>   bindPassword: ""
>
>   insecure: true
>
>   url: "ldap://adv1.aavn.local:389/...
>
>
Please advise me how to fix that.
Thanks.

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Default Service Account Names

[Jordan Liggitt]

An export should include custom image pull or push secrets added to the
namespace and included in the service account's imagePullSecrets list.

On Mon, Jul 17, 2017 at 8:04 AM, Clayton Coleman 
wrote:

> Also, if you exported a set of service accounts, assumption is that a new
> one can be added at any time (to all namespaces), which means you already
> have to handle merging them when you restore.
>
> On Mon, Jul 17, 2017 at 7:45 AM, Michail Kargakis 
> wrote:
>
>> What if someone has granted extra access to one of the default service
>> accounts? Custom deployments (and I imagine builds too)
>> may not work w/o granting extra permissions, depending on what the
>> deployer/builder is actually doing.
>>
>> On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin 
>> wrote:
>>
>>> I've been working on project archival for online, with regard to
>>> service accounts we may need to export those created manually by the
>>> user, and skip those created automatically by OpenShift when we
>>> created the project.
>>>
>>> There does not appear to be any information on those service accounts
>>> to identify that it was automatically created by OpenShift:
>>>
>>> - apiVersion: v1
>>>   imagePullSecrets:
>>>   - name: deployer-dockercfg-t2ckf
>>>   kind: ServiceAccount
>>>   metadata:
>>> creationTimestamp: 2017-07-12T14:48:19Z
>>> name: deployer
>>> namespace: myproject
>>>
>>>
>>> Is assuming the service accounts with names "builder", "deployer", and
>>> "default" a stable set we could count on for skipping during an
>>> export?
>>>
>>> Would it be acceptable to start adding an annotation to these service
>>> accounts similar to what we do for secrets that are attached to those
>>> SAs?
>>>
>>>   kind: Secret
>>>   metadata:
>>> annotations:
>>>   kubernetes.io/created-by: openshift.io/create-dockercfg-secrets
>>>
>>> Perhaps in this case "openshift.io/default-service-accounts"?
>>> (suggestions welcome)
>>>
>>> If so, is there any established precedent for migrating pre-existing
>>> builder/deployer/default SAs to add the annotation during an upgrade?
>>>
>>> Thanks!
>>>
>>> Devan
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Why openshift requires DNS server

[Jordan Liggitt]

> Why does separate dns server need? Could kube-dns be used?

kube-dns is actually a separate dns server as well. Openshift's DNS
implementation resolves some of the scalability issues kube-dns has and is
preferred


On Jul 13, 2017, at 6:20 AM, Haoran Wang  wrote:

Hi,
1. when you setup your cluster, you will have some node that running a
router pod,and  you need have a subdomain for your cluster, for example,
you cluster will use product.example.com, so you need the DNS server
setting forward the request with this DNS name prefix product.example.com to
the router node.

2. Assume create a project named test, and  you deploy an app to the
openshift cluster, you need create a route [1] for external access,  after
you do that, the url you can be access is by test.product.example.com.
 when you access the your app from outside, the general flow will be:

1. public dns server redirect you to your DNS server
2. Your dns server forward your request to one of the  node which have
openshift router pod deployed
3. the router pod(it's running haproxy by default) will forward the request
to the running pods

Hope this can help you. :)


[1]https://docs.openshift.org/latest/dev_guide/routes.html

Regards,
Haoran Wang

OpenShift QE
IRC: haowang
Raycom office - Red Hat China
Direct: +86 10  <+86%2010%206562%207492>65339430(ext-8389430)


On Thu, Jul 13, 2017 at 5:47 PM, bmeng  wrote:

> AFAIK, the kube-dns resolve the service-names inside the cluster.
>
> The dns server required by OpenShift gives the applications external
> accessibility.
>
> With the dns resolution and the route you created for your application,
> you can access your web application anywhere.
>
> On 07/13/2017 05:09 PM, Yu Wei wrote:
>
> Hi,
>
> I'm learning OpenShift by setting up cluster with VMs.
>
> From the document, some content about DNS is as below,
>
> *OpenShift Origin requires a fully functional DNS server in the
> environment. This is ideally a separate host running DNS software and can
> provide name resolution to hosts and containers running on the platform.*
>
>
> Why does separate dns server need? Could kub-dns be used?
>
>
> Thanks,
>
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
>
>
> ___
> users mailing 
> listusers@lists.openshift.redhat.comhttp://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Origin Active Directory Authentication

[Jordan Liggitt]

On Wed, Jul 12, 2017 at 11:44 PM, Steve Kuznetsov 
wrote:

> You could look at master logs:
>
> journalctl --unit atomic-openshift-master.service
>
> But I think Jordan was looking for client logs, so:
>
> oc login ... --loglevel 4
>

Not client logs, server logs with the server having been started with
loglevel 4




>
> On Jul 12, 2017 8:38 PM, "Werner, Mark"  wrote:
>
>> Jordan,
>>
>>
>>
>> Do you happen to know what journalctl command to use to view logs related
>> to logons?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>>
>> Unisys | Mobile Phone 586.214.9017 <(586)%20214-9017> |
>> mark.wer...@unisys.com
>>
>> 11720 Plaza America Drive, Reston, VA 20190
>>
>>
>>
>> [image: unisys_logo] <http://www.unisys.com/>
>>
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is for use only by the intended recipient. If you received
>> this in error, please contact the sender and delete the e-mail and its
>> attachments from all devices.
>>
>> [image: Grey_LI] <http://www.linkedin.com/company/unisys>  [image:
>> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
>> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
>> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
>> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
>> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>>
>>
>>
>> *From:* Jordan Liggitt [mailto:jligg...@redhat.com]
>> *Sent:* Wednesday, July 12, 2017 11:15 PM
>> *To:* Werner, Mark 
>> *Cc:* Derek Wright ;
>> dev@lists.openshift.redhat.com
>> *Subject:* Re: OpenShift Origin Active Directory Authentication
>>
>>
>>
>> Bump up the log level on the apiserver to 4 (--loglevel=4) and capture
>> the log messages during a login attempt
>>
>>
>>
>> On Wed, Jul 12, 2017 at 11:05 PM, Werner, Mark 
>> wrote:
>>
>> Thank you. That is what I was kind of assuming. And there is my problem.
>> I cannot get a successful logon with an AD user. I am out of ideas. It is
>> easy enough to delete old identity bindings with oc delete identity
>> :.
>>
>>
>>
>> I just can’t seem to understand why I cannot get AD authentication to
>> work.
>>
>>
>>
>> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>>
>> Unisys | Mobile Phone 586.214.9017 <(586)%20214-9017> |
>> mark.wer...@unisys.com
>>
>> 11720 Plaza America Drive, Reston, VA 20190
>>
>>
>>
>> [image: unisys_logo] <http://www.unisys.com/>
>>
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is for use only by the intended recipient. If you received
>> this in error, please contact the sender and delete the e-mail and its
>> attachments from all devices.
>>
>> [image: Grey_LI] <http://www.linkedin.com/company/unisys>  [image:
>> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
>> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
>> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
>> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
>> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>>
>>
>>
>> *From:* Jordan Liggitt [mailto:jligg...@redhat.com]
>> *Sent:* Wednesday, July 12, 2017 10:58 PM
>>
>>
>> *To:* Werner, Mark 
>> *Cc:* Derek Wright ;
>> dev@lists.openshift.redhat.com
>> *Subject:* Re: OpenShift Origin Active Directory Authentication
>>
>>
>>
>> Configuring a new identity provider does not remove Identity objects
>> created by a previously configured provider, which is why the allow_all
>> object still exists.
>>
>> Also, until you get a successful login with your new LDAP identity
>> provider, you won't see any Identity objects created by it.
>>
>>
>>
>>
>>
>> On Wed, Jul 12, 2017 at 10:55 PM, Werner, Mark 
>> wrote:
>>
>> No, the name is AD. But as I understand it the name is arbitrary.
>>
>>
>>
>> The kind is set to LDAPPasswordIdentityProvider, which replaced
>> allow_all. As I understand it this defines the type of Identity Provider.
>>
>>
>>
>

Re: OpenShift Origin Active Directory Authentication

[Jordan Liggitt]

Bump up the log level on the apiserver to 4 (--loglevel=4) and capture the
log messages during a login attempt

On Wed, Jul 12, 2017 at 11:05 PM, Werner, Mark 
wrote:

> Thank you. That is what I was kind of assuming. And there is my problem. I
> cannot get a successful logon with an AD user. I am out of ideas. It is
> easy enough to delete old identity bindings with oc delete identity
> :.
>
>
>
> I just can’t seem to understand why I cannot get AD authentication to work.
>
>
>
> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>
> Unisys | Mobile Phone 586.214.9017 <(586)%20214-9017> |
> mark.wer...@unisys.com
>
> 11720 Plaza America Drive, Reston, VA 20190
>
>
>
> [image: unisys_logo] <http://www.unisys.com/>
>
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all devices.
>
> [image: Grey_LI] <http://www.linkedin.com/company/unisys>  [image:
> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>
>
>
> *From:* Jordan Liggitt [mailto:jligg...@redhat.com]
> *Sent:* Wednesday, July 12, 2017 10:58 PM
>
> *To:* Werner, Mark 
> *Cc:* Derek Wright ;
> dev@lists.openshift.redhat.com
> *Subject:* Re: OpenShift Origin Active Directory Authentication
>
>
>
> Configuring a new identity provider does not remove Identity objects
> created by a previously configured provider, which is why the allow_all
> object still exists.
>
> Also, until you get a successful login with your new LDAP identity
> provider, you won't see any Identity objects created by it.
>
>
>
>
>
> On Wed, Jul 12, 2017 at 10:55 PM, Werner, Mark 
> wrote:
>
> No, the name is AD. But as I understand it the name is arbitrary.
>
>
>
> The kind is set to LDAPPasswordIdentityProvider, which replaced allow_all.
> As I understand it this defines the type of Identity Provider.
>
>
>
> name: AD
>
> provider:
>
>   apiVersion: v1
>
>   attributes:
>
> email:
>
> - mail
>
> id:
>
> - dn
>
> name:
>
> - displayName
>
> preferredUsername:
>
> - sAMAccountName
>
>   bindDN: CN=OpenShift User,OU=users,DC=domain,DC=local
>
>   bindPassword: password
>
>   insecure: true
>
>   kind: LDAPPasswordIdentityProvider
>
>
>
>
>
> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>
> Unisys | Mobile Phone 586.214.9017 <(586)%20214-9017> |
> mark.wer...@unisys.com
>
> 11720 Plaza America Drive, Reston, VA 20190
>
>
>
> [image: unisys_logo] <http://www.unisys.com/>
>
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all devices.
>
> [image: Grey_LI] <http://www.linkedin.com/company/unisys>  [image:
> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>
>
>
> *From:* Jordan Liggitt [mailto:jligg...@redhat.com]
> *Sent:* Wednesday, July 12, 2017 10:49 PM
> *To:* Werner, Mark 
> *Cc:* Derek Wright ;
> dev@lists.openshift.redhat.com
> *Subject:* Re: OpenShift Origin Active Directory Authentication
>
>
>
>
>
>
>
> On Wed, Jul 12, 2017 at 10:41 PM, Werner, Mark 
> wrote:
>
> I am wondering why, if I perform a “oc get identity” that the only
> identity that is returned is allow_all? If I changed the master-config.yaml
> file to only have the Identity Provider AllowAllPasswordIdentityProvider,
> then restart the origin=master service. Why doesn’t “oc get identity”
> return AllowAllPasswordIdentityProvider and still returns allow_all?
>
>
>
> The name of your AllowAllPasswordIdentityProvider identity provider was
> "allow_all", right?
>
> name: allow_all
>
>
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Origin Active Directory Authentication

[Jordan Liggitt]

Configuring a new identity provider does not remove Identity objects
created by a previously configured provider, which is why the allow_all
object still exists.

Also, until you get a successful login with your new LDAP identity
provider, you won't see any Identity objects created by it.


On Wed, Jul 12, 2017 at 10:55 PM, Werner, Mark 
wrote:

> No, the name is AD. But as I understand it the name is arbitrary.
>
>
>
> The kind is set to LDAPPasswordIdentityProvider, which replaced allow_all.
> As I understand it this defines the type of Identity Provider.
>
>
>
> name: AD
>
> provider:
>
>   apiVersion: v1
>
>   attributes:
>
> email:
>
> - mail
>
> id:
>
> - dn
>
> name:
>
> - displayName
>
> preferredUsername:
>
> - sAMAccountName
>
>   bindDN: CN=OpenShift User,OU=users,DC=domain,DC=local
>
>   bindPassword: password
>
>   insecure: true
>
>   kind: LDAPPasswordIdentityProvider
>
>
>
>
>
> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>
> Unisys | Mobile Phone 586.214.9017 <(586)%20214-9017> |
> mark.wer...@unisys.com
>
> 11720 Plaza America Drive, Reston, VA 20190
>
>
>
> [image: unisys_logo] <http://www.unisys.com/>
>
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all devices.
>
> [image: Grey_LI] <http://www.linkedin.com/company/unisys>  [image:
> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>
>
>
> *From:* Jordan Liggitt [mailto:jligg...@redhat.com]
> *Sent:* Wednesday, July 12, 2017 10:49 PM
> *To:* Werner, Mark 
> *Cc:* Derek Wright ;
> dev@lists.openshift.redhat.com
> *Subject:* Re: OpenShift Origin Active Directory Authentication
>
>
>
>
>
>
>
> On Wed, Jul 12, 2017 at 10:41 PM, Werner, Mark 
> wrote:
>
> I am wondering why, if I perform a “oc get identity” that the only
> identity that is returned is allow_all? If I changed the master-config.yaml
> file to only have the Identity Provider AllowAllPasswordIdentityProvider,
> then restart the origin=master service. Why doesn’t “oc get identity”
> return AllowAllPasswordIdentityProvider and still returns allow_all?
>
>
>
> The name of your AllowAllPasswordIdentityProvider identity provider was
> "allow_all", right?
>
> name: allow_all
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Origin Active Directory Authentication

[Jordan Liggitt]

On Wed, Jul 12, 2017 at 10:41 PM, Werner, Mark 
wrote:

> I am wondering why, if I perform a “oc get identity” that the only
> identity that is returned is allow_all? If I changed the master-config.yaml
> file to only have the Identity Provider AllowAllPasswordIdentityProvider,
> then restart the origin=master service. Why doesn’t “oc get identity”
> return AllowAllPasswordIdentityProvider and still returns allow_all?
>


The name of your AllowAllPasswordIdentityProvider identity provider was
"allow_all", right?

name: allow_all


___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: API health or status page

[Jordan Liggitt]

See the cluster-status role as an example:

oc export clusterroles cluster-status -o yaml > myrole.yaml


Change the name to a custom name, and include only the urls you would want
anonymous users to access

Then create the custom role:
oc create -f myrole.yaml

And grant it to anonymous users:
oadm policy add-cluster-role-to-group my-role-name system:unauthenticated




On Thu, Feb 9, 2017 at 5:18 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> That is interesting, indeed what I want.
>
>
>
> Can you share step by step or any document which explains?
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, February 9, 2017 at 1:57 PM
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: API health or status page
>
>
>
> You can set up a role that allows access to the API endpoints you want,
> and bind that role to the `system:unauthenticated` group, and it will allow
> accessing that API without any authentication.
>
>
>
>
> On Thu, Feb 9, 2017 at 4:55 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> Can I use any API call without authentication? I need an API URL to put
> into my monitoring agent to periodically check health. All most all API
> calls need token or authentication. Although I can use a service account
> and use secret as a token since it doesn’t expire, am looking for a simple
> solution if possible
>
>
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: API health or status page

[Jordan Liggitt]

You can set up a role that allows access to the API endpoints you want, and
bind that role to the `system:unauthenticated` group, and it will allow
accessing that API without any authentication.




On Thu, Feb 9, 2017 at 4:55 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> Can I use any API call without authentication? I need an API URL to put
> into my monitoring agent to periodically check health. All most all API
> calls need token or authentication. Although I can use a service account
> and use secret as a token since it doesn’t expire, am looking for a simple
> solution if possible
>
>
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Important: hold on installing/upgrading to Origin 1.4.0

[Jordan Liggitt]

Origin 1.4.1 is now available and fixes this issue.

https://github.com/openshift/origin/releases/tag/v1.4.1

On Mon, Jan 23, 2017 at 11:04 AM, Jordan Liggitt 
wrote:

> An issue[1] was reported that upgrading to 1.4.0 causes existing user
> logins to stop working.
>
> The location in etcd where user identities are stored was inadvertently
> changed during the 1.4 dev cycle, causing existing identities to appear
> missing, and new identities to be stored in an incorrect location.
>
> We're working to expedite a hot-fix restoring the previous behavior. Until
> that hot-fix is available, installing/upgrading to 1.4.0 is not
> recommended. A follow-up announcement will be made when the fix is
> available.
>
> Thanks to the community for quickly reporting the issue. Additional tests
> will be added to ensure storage locations remain stable in the future.
>
>
> Jordan
>
>
> [1] https://github.com/openshift/origin/issues/12598
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Important: hold on installing/upgrading to Origin 1.4.0

[Jordan Liggitt]

An issue[1] was reported that upgrading to 1.4.0 causes existing user
logins to stop working.

The location in etcd where user identities are stored was inadvertently
changed during the 1.4 dev cycle, causing existing identities to appear
missing, and new identities to be stored in an incorrect location.

We're working to expedite a hot-fix restoring the previous behavior. Until
that hot-fix is available, installing/upgrading to 1.4.0 is not
recommended. A follow-up announcement will be made when the fix is
available.

Thanks to the community for quickly reporting the issue. Additional tests
will be added to ensure storage locations remain stable in the future.


Jordan


[1] https://github.com/openshift/origin/issues/12598
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Upstream PRs to Origin are on hold pending the rebase

[Jordan Liggitt]

Also, the security issue with kube 1.5 was an issue with authorization
related to authenticated/anonymous users. Because OpenShift has always
distinguished between those types of users in authentication and
authorization, the issue does not affect OpenShift.

On Tue, Jan 3, 2017 at 2:13 PM, Marky Jackson 
wrote:

> ok, thank you for explaining that :-)
>
> On Tue, Jan 3, 2017 at 11:13 AM, Clayton Coleman 
> wrote:
>
>> Origin 1.5 is in alpha right now - we trail Kube specifically to catch
>> these issues and also to ensure all security policies for multi-tenancy are
>> adapted / enforced.
>>
>> On Jan 3, 2017, at 2:11 PM, Andy Goldstein  wrote:
>>
>> We will pull in Kubernetes 1.5.1 prior to releasing Origin 1.5. As soon
>> as https://github.com/openshift/origin/pull/12143 merges, we will begin
>> another PR to pull in Kubernetes 1.5.1.
>>
>> Andy
>>
>> On Tue, Jan 3, 2017 at 2:06 PM, Marky Jackson 
>> wrote:
>>
>>> So this will go out with the security vulnerability that exist in 1.5?
>>> Is  there a timeframe/roadmap to 1.5.1?
>>>
>>> On Tue, Jan 3, 2017 at 11:02 AM, Andy Goldstein 
>>> wrote:
>>>
 Not yet, but soon. The current PR (https://github.com/openshift/
 origin/pull/12143) pulls in Kubernetes tag v1.5.0-beta.2 because the
 rebase work was started in late November/early December. Once this PR is
 merged, we will do a follow-up to pull in the latest Kubernetes 1.5.x. tag,
 currently v1.5.1.

 On Tue, Jan 3, 2017 at 1:58 PM, Marky Jackson >>> > wrote:

> Do you mean 1.5.1?
>
> On Tue, Jan 3, 2017 at 10:55 AM, Andy Goldstein 
> wrote:
>
>> All, please hold off opening UPSTREAM PRs to Origin. We are
>> finalizing the rebase of Kubernetes 1.5 into Origin, and we'll accept new
>> upstream pulls once the rebase lands.
>>
>> Thanks,
>> Andy
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
>
> --
> *Marky Jackson*
>
> DevTools Software Engineer, Taulia Inc.
>
> m: (408) 464 2965 <(408)%20464-2965> | e: marky.jack...@taulia.com  hivani.kote...@taulia.com>
>  | w: www.taulia.com 
> | a: 201
> Mission St. Suite 900 San Francisco CA 94105
>


>>>
>>>
>>> --
>>> *Marky Jackson*
>>>
>>> DevTools Software Engineer, Taulia Inc.
>>>
>>> m: (408) 464 2965 <(408)%20464-2965> | e: marky.jack...@taulia.com >> hivani.kote...@taulia.com>
>>>  | w: www.taulia.com 
>>> | a: 201
>>> Mission St. Suite 900 San Francisco CA 94105
>>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
>
> --
> *Marky Jackson*
>
> DevTools Software Engineer, Taulia Inc.
>
> m: (408) 464 2965 <(408)%20464-2965> | e: marky.jack...@taulia.com  hivani.kote...@taulia.com>
>  | w: www.taulia.com   |
> a: 201
> Mission St. Suite 900 San Francisco CA 94105
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: enable logs for openshift master

[Jordan Liggitt]

Passing `--loglevel=5` to `openshift start master` prints verbose logs

On Thu, Dec 22, 2016 at 9:42 AM, Pri  wrote:

> Hi,
>
> Is there a way we can enable DEBUG logs for openshift master, may be by
> editing master-config.yaml. Please let me know if its possible?
>
> Thanks,
> Pri
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: cluster wide service acount

[Jordan Liggitt]

It's referenced in the dockercfg secret openshift.io/token-secret.name
annotation

On Fri, Dec 2, 2016 at 9:32 AM, Mateus Caruccio <
mateus.caruc...@getupcloud.com> wrote:

> It would be nice if I could identify which token belongs to dockercfg.
> Maybe by name like "cae-ops-dockercfg-token-5vrkf"
>
> --
> Mateus Caruccio / Master of Puppets
> GetupCloud.com - Eliminamos a Gravidade
>
> On Fri, Dec 2, 2016 at 12:18 PM, Jordan Liggitt 
> wrote:
>
>> They are managed by different controllers, and it gives you individual
>> revocation ability.
>>
>> On Dec 2, 2016, at 9:14 AM, Aaron Weitekamp  wrote:
>>
>> On Thu, Dec 1, 2016 at 5:19 PM, Jordan Liggitt 
>> wrote:
>>
>>> The dockercfg secret contains the value of one of the tokens (which is
>>> required to exist in order for the service account token to continue to be
>>> a valid credential) in dockercfg format
>>>
>>> ​This has been a source of confusion. I understand the need for a
>> separate dockercfg SA that references an actual token, but why the second
>> token? It's seems unnecessary and users don't know which one to use, why
>> it's there, etc.
>> ​
>>
>>
>>> On Thu, Dec 1, 2016 at 4:59 PM, Srinivas Naga Kotaru (skotaru) <
>>> skot...@cisco.com> wrote:
>>>
>>>> For Docker login purpose, I could see another token ( I think this is
>>>> what you are talking about)
>>>>
>>>>
>>>>
>>>> cae-ops-dockercfg-04ccdkubernetes.io/dockercfg
>>>>1 1h
>>>>
>>>> cae-ops-token-5vrkfkubernetes.io/service-account-token
>>>> 3 1h
>>>>
>>>> cae-ops-token-jdhezkubernetes.io/service-account-token
>>>> 3 1h
>>>>
>>>>
>>>>
>>>> 1st token being used for Docker. Was wondering about other 2 tokens.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Srinivas Kotaru*
>>>>
>>>>
>>>>
>>>> *From: *Jordan Liggitt 
>>>> *Date: *Thursday, December 1, 2016 at 1:39 PM
>>>>
>>>> *To: *Srinivas Naga Kotaru 
>>>> *Cc: *dev 
>>>> *Subject: *Re: cluster wide service acount
>>>>
>>>>
>>>>
>>>> One token is the one generated to mount into pods that run as the
>>>> service account.
>>>>
>>>> The other is the one wrapped into a dockercfg secret used as a
>>>> credential against the internal docker registry.
>>>>
>>>>
>>>>
>>>> On Thu, Dec 1, 2016 at 3:56 PM, Srinivas Naga Kotaru (skotaru) <
>>>> skot...@cisco.com> wrote:
>>>>
>>>> Thanks, it is working.  Able to login using service account token
>>>>
>>>>
>>>>
>>>> # oc get sa
>>>>
>>>> # oc get secrets
>>>>
>>>> #  oc get  secret  cae-ops-token-5vrkf  --template='{{.data.token}}'
>>>>
>>>>
>>>>
>>>> decode base64 token
>>>>
>>>>
>>>>
>>>> # oc login –token=
>>>>
>>>>
>>>>
>>>> *Qeustion:*
>>>>
>>>>
>>>>
>>>> I can see 2 secrets for each service accont and both are valied to
>>>> login. Any idea why 2 ?
>>>>
>>>>
>>>>
>>>> # oc get secrets
>>>>
>>>>
>>>>
>>>> cae-ops-token-5vrkfkubernetes.io/service-account-token
>>>> 3 35m
>>>>
>>>> cae-ops-token-jdhezkubernetes.io/service-account-token
>>>> 3 35m
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Srinivas Kotaru*
>>>>
>>>>
>>>>
>>>> *From: *Jordan Liggitt 
>>>> *Date: *Thursday, December 1, 2016 at 12:26 PM
>>>>
>>>>
>>>> *To: *Srinivas Naga Kotaru 
>>>> *Cc: *dev 
>>>> *Subject: *Re: cluster wide service acount
>>>>
>>>>
>>>>
>>>> If you have the service account's token, you can use it from the
>>>> command line like this:
>>>>
>>>> oc login --token=...
>>>>
>>>>
>>>>
>>>> The web console 

Re: cluster wide service acount

[Jordan Liggitt]

They are managed by different controllers, and it gives you individual
revocation ability.

On Dec 2, 2016, at 9:14 AM, Aaron Weitekamp  wrote:

On Thu, Dec 1, 2016 at 5:19 PM, Jordan Liggitt  wrote:

> The dockercfg secret contains the value of one of the tokens (which is
> required to exist in order for the service account token to continue to be
> a valid credential) in dockercfg format
>
> ​This has been a source of confusion. I understand the need for a separate
dockercfg SA that references an actual token, but why the second token?
It's seems unnecessary and users don't know which one to use, why it's
there, etc.
​


> On Thu, Dec 1, 2016 at 4:59 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
>> For Docker login purpose, I could see another token ( I think this is
>> what you are talking about)
>>
>>
>>
>> cae-ops-dockercfg-04ccdkubernetes.io/dockercfg
>>1 1h
>>
>> cae-ops-token-5vrkfkubernetes.io/service-account-token
>> 3 1h
>>
>> cae-ops-token-jdhezkubernetes.io/service-account-token
>> 3 1h
>>
>>
>>
>> 1st token being used for Docker. Was wondering about other 2 tokens.
>>
>>
>>
>> --
>>
>> *Srinivas Kotaru*
>>
>>
>>
>> *From: *Jordan Liggitt 
>> *Date: *Thursday, December 1, 2016 at 1:39 PM
>>
>> *To: *Srinivas Naga Kotaru 
>> *Cc: *dev 
>> *Subject: *Re: cluster wide service acount
>>
>>
>>
>> One token is the one generated to mount into pods that run as the service
>> account.
>>
>> The other is the one wrapped into a dockercfg secret used as a credential
>> against the internal docker registry.
>>
>>
>>
>> On Thu, Dec 1, 2016 at 3:56 PM, Srinivas Naga Kotaru (skotaru) <
>> skot...@cisco.com> wrote:
>>
>> Thanks, it is working.  Able to login using service account token
>>
>>
>>
>> # oc get sa
>>
>> # oc get secrets
>>
>> #  oc get  secret  cae-ops-token-5vrkf  --template='{{.data.token}}'
>>
>>
>>
>> decode base64 token
>>
>>
>>
>> # oc login –token=
>>
>>
>>
>> *Qeustion:*
>>
>>
>>
>> I can see 2 secrets for each service accont and both are valied to login.
>> Any idea why 2 ?
>>
>>
>>
>> # oc get secrets
>>
>>
>>
>> cae-ops-token-5vrkfkubernetes.io/service-account-token
>> 3 35m
>>
>> cae-ops-token-jdhezkubernetes.io/service-account-token
>> 3 35m
>>
>>
>>
>> --
>>
>> *Srinivas Kotaru*
>>
>>
>>
>> *From: *Jordan Liggitt 
>> *Date: *Thursday, December 1, 2016 at 12:26 PM
>>
>>
>> *To: *Srinivas Naga Kotaru 
>> *Cc: *dev 
>> *Subject: *Re: cluster wide service acount
>>
>>
>>
>> If you have the service account's token, you can use it from the command
>> line like this:
>>
>> oc login --token=...
>>
>>
>>
>> The web console does not provide a way to log in with a service account
>> token.
>>
>>
>>
>> On Thu, Dec 1, 2016 at 3:19 PM, Srinivas Naga Kotaru (skotaru) <
>> skot...@cisco.com> wrote:
>>
>> Jordan
>>
>>
>>
>> That helps. Thanks for quick help.
>>
>>
>>
>> Can we use this sa account to login into console and OC clinet? If yes
>> how? I knew SA account only has non expired token but no password
>>
>>
>>
>>
>>
>> --
>>
>> *Srinivas Kotaru*
>>
>>
>>
>> *From: *Jordan Liggitt 
>> *Date: *Thursday, December 1, 2016 at 12:04 PM
>> *To: *Srinivas Naga Kotaru 
>> *Cc: *dev 
>> *Subject: *Re: cluster wide service acount
>>
>>
>>
>> Service accounts exist within a namespace but can be granted permissions
>> across the entire cluster, just like any other user. For example:
>>
>> oadm policy add-cluster-role-to-user cluster-reader
>> system:serviceaccount:openshift-infra:monitor-service-account
>>
>>
>>
>> On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) <
>> skot...@cisco.com> wrote:
>>
>> I knew we can create a service account per project and can be used as a
>> password less API work and automations activities. Can we create a service
>> account at cluster level and can be used for platform operations
>> (monitoring, automation, shared account for operation teams)?
>>
>>
>>
>> Intention is to have expiry free tokens.
>>
>>
>>
>> --
>>
>> *Srinivas Kotaru*
>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>>
>>
>>
>>
>>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: cluster wide service acount

[Jordan Liggitt]

The dockercfg secret contains the value of one of the tokens (which is
required to exist in order for the service account token to continue to be
a valid credential) in dockercfg format

On Thu, Dec 1, 2016 at 4:59 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> For Docker login purpose, I could see another token ( I think this is what
> you are talking about)
>
>
>
> cae-ops-dockercfg-04ccdkubernetes.io/dockercfg
>1 1h
>
> cae-ops-token-5vrkfkubernetes.io/service-account-token
> 3 1h
>
> cae-ops-token-jdhezkubernetes.io/service-account-token
> 3 1h
>
>
>
> 1st token being used for Docker. Was wondering about other 2 tokens.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 1:39 PM
>
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> One token is the one generated to mount into pods that run as the service
> account.
>
> The other is the one wrapped into a dockercfg secret used as a credential
> against the internal docker registry.
>
>
>
> On Thu, Dec 1, 2016 at 3:56 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> Thanks, it is working.  Able to login using service account token
>
>
>
> # oc get sa
>
> # oc get secrets
>
> #  oc get  secret  cae-ops-token-5vrkf  --template='{{.data.token}}'
>
>
>
> decode base64 token
>
>
>
> # oc login –token=
>
>
>
> *Qeustion:*
>
>
>
> I can see 2 secrets for each service accont and both are valied to login.
> Any idea why 2 ?
>
>
>
> # oc get secrets
>
>
>
> cae-ops-token-5vrkfkubernetes.io/service-account-token
> 3 35m
>
> cae-ops-token-jdhezkubernetes.io/service-account-token
> 3 35m
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 12:26 PM
>
>
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> If you have the service account's token, you can use it from the command
> line like this:
>
> oc login --token=...
>
>
>
> The web console does not provide a way to log in with a service account
> token.
>
>
>
> On Thu, Dec 1, 2016 at 3:19 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> Jordan
>
>
>
> That helps. Thanks for quick help.
>
>
>
> Can we use this sa account to login into console and OC clinet? If yes
> how? I knew SA account only has non expired token but no password
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 12:04 PM
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> Service accounts exist within a namespace but can be granted permissions
> across the entire cluster, just like any other user. For example:
>
> oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:
> openshift-infra:monitor-service-account
>
>
>
> On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> I knew we can create a service account per project and can be used as a
> password less API work and automations activities. Can we create a service
> account at cluster level and can be used for platform operations
> (monitoring, automation, shared account for operation teams)?
>
>
>
> Intention is to have expiry free tokens.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
>
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: cluster wide service acount

[Jordan Liggitt]

One token is the one generated to mount into pods that run as the service
account.

The other is the one wrapped into a dockercfg secret used as a credential
against the internal docker registry.


On Thu, Dec 1, 2016 at 3:56 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> Thanks, it is working.  Able to login using service account token
>
>
>
> # oc get sa
>
> # oc get secrets
>
> #  oc get  secret  cae-ops-token-5vrkf  --template='{{.data.token}}'
>
>
>
> decode base64 token
>
>
>
> # oc login –token=
>
>
>
> *Qeustion:*
>
>
>
> I can see 2 secrets for each service accont and both are valied to login.
> Any idea why 2 ?
>
>
>
> # oc get secrets
>
>
>
> cae-ops-token-5vrkfkubernetes.io/service-account-token
> 3 35m
>
> cae-ops-token-jdhezkubernetes.io/service-account-token
> 3 35m
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 12:26 PM
>
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> If you have the service account's token, you can use it from the command
> line like this:
>
> oc login --token=...
>
>
>
> The web console does not provide a way to log in with a service account
> token.
>
>
>
> On Thu, Dec 1, 2016 at 3:19 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> Jordan
>
>
>
> That helps. Thanks for quick help.
>
>
>
> Can we use this sa account to login into console and OC clinet? If yes
> how? I knew SA account only has non expired token but no password
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 12:04 PM
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> Service accounts exist within a namespace but can be granted permissions
> across the entire cluster, just like any other user. For example:
>
> oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:
> openshift-infra:monitor-service-account
>
>
>
> On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> I knew we can create a service account per project and can be used as a
> password less API work and automations activities. Can we create a service
> account at cluster level and can be used for platform operations
> (monitoring, automation, shared account for operation teams)?
>
>
>
> Intention is to have expiry free tokens.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: cluster wide service acount

[Jordan Liggitt]

If you have the service account's token, you can use it from the command
line like this:

oc login --token=...

The web console does not provide a way to log in with a service account
token.


On Thu, Dec 1, 2016 at 3:19 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> Jordan
>
>
>
> That helps. Thanks for quick help.
>
>
>
> Can we use this sa account to login into console and OC clinet? If yes
> how? I knew SA account only has non expired token but no password
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Thursday, December 1, 2016 at 12:04 PM
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: cluster wide service acount
>
>
>
> Service accounts exist within a namespace but can be granted permissions
> across the entire cluster, just like any other user. For example:
>
> oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:
> openshift-infra:monitor-service-account
>
>
>
> On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> I knew we can create a service account per project and can be used as a
> password less API work and automations activities. Can we create a service
> account at cluster level and can be used for platform operations
> (monitoring, automation, shared account for operation teams)?
>
>
>
> Intention is to have expiry free tokens.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: cluster wide service acount

[Jordan Liggitt]

Service accounts exist within a namespace but can be granted permissions
across the entire cluster, just like any other user. For example:

oadm policy add-cluster-role-to-user cluster-reader
system:serviceaccount:openshift-infra:monitor-service-account



On Thu, Dec 1, 2016 at 3:02 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> I knew we can create a service account per project and can be used as a
> password less API work and automations activities. Can we create a service
> account at cluster level and can be used for platform operations
> (monitoring, automation, shared account for operation teams)?
>
>
>
> Intention is to have expiry free tokens.
>
>
>
> --
>
> *Srinivas Kotaru*
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: The API version v1 for kind BuildConfig is not supported by this server.

[Jordan Liggitt]

What setup method did you use? Check your
/etc/origin/master/master-config.yaml to see if it contains a
"disabledFeatures" field that includes "Builder".



On Fri, Nov 18, 2016 at 12:28 AM, irvan hendrik 
wrote:

> Hi,
> I am completely new with OpenShift and docker. I set up the Openshift with
> 1 master, 2 nodes, 1 registry. I follows the documentation and I think I
> got them right, but I keep getting this error at my OpenShift web console.
>
>
> 
>
> I am the cluster admin with access to the master and nodes.
> Is there a configuration that I missed when setting up the Openshift
> Container Platform?
>
> Any help would be extremely appreciated.
> Thank you.
> Irvan Hendrik
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: namedCertificates not working

[Jordan Liggitt]

What does `curl -vvv https://` show?

On Tue, Nov 15, 2016 at 6:56 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> Issue got fixed. Am using a SAN cert and included individual master names
> also in the cert. I also included these individual master names in the
> configuration under names:
>
>
>
> names:
>
>   - "mastervip"
>
>   - "master1"
>
>  - "master2"
>
>   - "master3"
>
>
>
> after removing individual master names issue got fixed. Now configuration
> has just public URL
>
>
>
> able to see projects in the browser and CLI after authentication.
>
>
>
> However CURL and OC clients sill throwing warning  and not trusting
> certificate
>
>
>
> oc login https://masterpublicurl
>
>  The server uses a certificate signed by an unknown authority.
>
> You can bypass the certificate check, but any data you send to the server
> could be intercepted by others.
>
> Use insecure connections? (y/n):
>
>
>
> Any idea why? Althoght it is prod grade cert from well known CA.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Srinivas Naga Kotaru 
> *Date: *Tuesday, November 15, 2016 at 3:06 PM
> *To: *Jordan Liggitt 
>
> *Cc: *dev 
> *Subject: *Re: namedCertificates not working
>
>
>
> Nov 15 23:03:53 atomic-openshift-master-api[121472]: E1115
> 23:03:53.196173  121472 reflector.go:203] github.com/openshift/origin/
> pkg/project/auth/cache.go:188: Failed to list *api.Namespace: Get 
> https://
> /api/v1/namespaces?resourceVersion=0: x509: certificate signed by unknown
> authority
>
> Nov 15 23:03:53 atomic-openshift-master-api[121472]: I1115
> 23:03:53.204024  121472 server.go:2161] http: TLS handshake error from
> 64.101.6.3:42824: remote error: bad certificate
>
>
>
> Am wondering why this error sicne cert is fully valid. In fact, master
> console clearely showing green lock with right cert information.
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *Jordan Liggitt 
> *Date: *Tuesday, November 15, 2016 at 2:41 PM
> *To: *Srinivas Naga Kotaru 
> *Cc: *dev 
> *Subject: *Re: namedCertificates not working
>
>
>
> Are you seeing this from a system where you previously logged in to that
> URL using oc with the non-prod CA bundle? When configured to use a
> non-system-roots ca bundle, oc remembers it in the local user's kubeconfig
> file ($KUBECONFIG or ~/.kube/config).
>
>
>
> Try moving (or removing) the kubeconfig file and see if that allows oc to
> use the system roots to recognize the new certificates
>
>
>
>
>
>
>
>
> On Nov 15, 2016, at 5:30 PM, Srinivas Naga Kotaru (skotaru) <
> skot...@cisco.com> wrote:
>
> Trying to deploy prod grade cert to our prod installation.   Browser
> showing green light but CLI clients showing cert errors.  OC client unable
> to display any projects. Do we need to use cafile in the config? I couldn’t
> find right syntax . I tried caFile but no use.
>
>
>
> Although browser showing green light and showing correct cert info, unable
> to display any projects including default projects after authentication
>
>
>
> We are using separate URL for public and internal OpenShift communication.
> Public URL is load balanced with 3 masters. LB was configured with SS
> pass-through to masters and masters doing actual SSL offload.
>
>
>
> oc login https:// 1 ↵
>
> The server uses a certificate signed by an unknown authority.
>
> You can bypass the certificate check, but any data you send to the server
> could be intercepted by others.
>
> Use insecure connections? (y/n):
>
>
>
> oc project default
>   1 ↵
>
> Error from server: Get https:// /api/v1/namespaces/default:
> x509: certificate signed by unknown authority
>
>
>
> assetConfig:
>
>   logoutURL: ""
>
>   masterPublicURL: https://apivip
>
>   publicURL: https://apivip/console/
>
>   servingInfo:
>
> bindAddress: 0.0.0.0:443
>
> bindNetwork: tcp4
>
> certFile: master.server.crt
>
> clientCA: ""
>
> keyFile: master.server.key
>
> maxRequestsInFlight: 0
>
> requestTimeoutSeconds: 0
>
> namedCertificates:
>
>   - certFile: /opt/cae/certs/master/cae.crt
>
> keyFile: /opt/cae/certs/master/cae.key
>
> names:
>
>   - "mastervip"
>
>   - "master1"
>
>  - "master2"
>
>   - "

Re: namedCertificates not working

[Jordan Liggitt]

Are you seeing this from a system where you previously logged in to that
URL using oc with the non-prod CA bundle? When configured to use a
non-system-roots ca bundle, oc remembers it in the local user's kubeconfig
file ($KUBECONFIG or ~/.kube/config).

Try moving (or removing) the kubeconfig file and see if that allows oc to
use the system roots to recognize the new certificates




On Nov 15, 2016, at 5:30 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

Trying to deploy prod grade cert to our prod installation.   Browser
showing green light but CLI clients showing cert errors.  OC client unable
to display any projects. Do we need to use cafile in the config? I couldn’t
find right syntax . I tried caFile but no use.



Although browser showing green light and showing correct cert info, unable
to display any projects including default projects after authentication



We are using separate URL for public and internal OpenShift communication.
Public URL is load balanced with 3 masters. LB was configured with SS
pass-through to masters and masters doing actual SSL offload.



oc login https:// 1 ↵

The server uses a certificate signed by an unknown authority.

You can bypass the certificate check, but any data you send to the server
could be intercepted by others.

Use insecure connections? (y/n):



oc project default
  1 ↵

Error from server: Get https:// /api/v1/namespaces/default: x509:
certificate signed by unknown authority



assetConfig:

  logoutURL: ""

  masterPublicURL: https://apivip

  publicURL: https://apivip/console/

  servingInfo:

bindAddress: 0.0.0.0:443

bindNetwork: tcp4

certFile: master.server.crt

clientCA: ""

keyFile: master.server.key

maxRequestsInFlight: 0

requestTimeoutSeconds: 0

namedCertificates:

  - certFile: /opt/cae/certs/master/cae.crt

keyFile: /opt/cae/certs/master/cae.key

names:

  - "mastervip"

  - "master1"

 - "master2"

  - "master3"



servingInfo:

  bindAddress: 0.0.0.0:443

  bindNetwork: tcp4

  certFile: master.server.crt

  clientCA: ca.crt

  keyFile: master.server.key

  maxRequestsInFlight: 500

  requestTimeoutSeconds: 3600

  namedCertificates:

- certFile: /opt/cae/certs/master/cae.crt

  keyFile: /opt/cae/certs/master/cae.key

names:

  - "mastervip"

  - "master1"

 - "master2"

  - "master3"





-- 

*Srinivas Kotaru*

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Kerberos support in `oc login`

[Jordan Liggitt]

https://github.com/openshift/origin/pull/4566 adds Kerberos support to `oc
login` on Linux and OS X, via GSSAPI library bindings.

Release builds will enable this support in the Linux build of `oc`, but
because additional headers are required to build, simple builds
(`hack/build-go.sh` or `make build`) will not include GSSAPI support.

You can use `oc version` to see if GSSAPI support is enabled:

$ oc version
oc v1.3.0-alpha.2+5bf1b69
kubernetes v1.3.0+57fb9ac
features: Basic-Auth GSSAPI Kerberos SPNEGO

For more information about building with GSSAPI support, see
https://github.com/openshift/origin/blob/master/HACKING.md#gssapi-enabled-builds

Server-side, Kerberos was already supported via the
RequestHeaderIdentityProvider combined with a Kerberos-speaking
authenticating proxy.
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: is kubelet's cadvisor running in openshift node?

[Jordan Liggitt]

I think it accesses the /stats/ endpoints served by the kubelet (https://
:10250/stats/...)


On Fri, Jun 10, 2016 at 2:45 PM, Erik Jacobs  wrote:

> So perhaps I'm misunderstanding something but how does Heapster collect
> the information?
>
>
> Erik M Jacobs, RHCA
> Principal Technical Marketing Manager, OpenShift Enterprise
> Red Hat, Inc.
> Phone: 646.462.3745
> Email: ejac...@redhat.com
> AOL Instant Messenger: ejacobsatredhat
> Twitter: @ErikonOpen
> Freenode: thoraxe
>
> On Fri, Jun 10, 2016 at 2:33 PM, Jordan Liggitt 
> wrote:
>
>> It is running on the node, but is not surfaced via a port
>>
>> On Fri, Jun 10, 2016 at 2:15 PM, Alan Jones  wrote:
>>
>>> Is kubelet's cadvisor running in the OpenShift node and, if so, on what
>>> port (e.g. 10255)?
>>> Thank you!
>>> Alan
>>>
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: is kubelet's cadvisor running in openshift node?

[Jordan Liggitt]

It is running on the node, but is not surfaced via a port

On Fri, Jun 10, 2016 at 2:15 PM, Alan Jones  wrote:

> Is kubelet's cadvisor running in the OpenShift node and, if so, on what
> port (e.g. 10255)?
> Thank you!
> Alan
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Allow users to a Project

[Jordan Liggitt]

Currently, that has to be done via the command line (using the `oc policy`
commands). Project member management is planned for the web console, but
has not been implemented yet (see https://trello.com/c/365NeA8Y to track
that work)

On Fri, May 13, 2016 at 12:10 AM, David Dimas 
wrote:

> Hi.
> I am doing some integration work with Openshift Origin 1.1.6 and
> customizing Web console now.
>
> There is nothing in Web Console that allows you to invite users to a
> project (or even set up a User).
> And I have not seen anything that allows a project administrator to assign
> a specific role to a User.
>
> How can I allow users to a project( or set up a user)?
>
> Thanks in advance.
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: keystonepasswd auth

[Jordan Liggitt]

We don't use the token to make any other API calls, just to verify the
user's auth credentials.

On Thu, Apr 14, 2016 at 1:36 PM, Fox, Kevin M  wrote:

> Ah. There are scoped and unscoped tokens in keystone. Unscoped ones are
> project-less but can do almost nothing. Project scoped ones usually used.
>
> Most resources in openstack is bound to the project and not the user, so
> hence the need for scoped tokens.
>
> Thanks,
> Kevin
> ------
> *From:* Jordan Liggitt [jligg...@redhat.com]
> *Sent:* Thursday, April 14, 2016 9:53 AM
> *To:* Fox, Kevin M; Scott Seago
> *Cc:* Chmouel Boudjnah; OpenShift List Dev
> *Subject:* Re: keystonepasswd auth
>
> I'm not seeing where tenant name is defaulted to the user name. The
> keystone auth request is a password authentication with the user name and
> domain name, which uniquely identifies the user (users belong to domains,
> not tenants/projects)
>
> On Thu, Apr 14, 2016 at 12:20 PM, Fox, Kevin M  wrote:
>
>> keystone v3 renamed tenant to project. Otherwise, should be the same.
>>
>> Thanks,
>> Kevin
>>
>>
>> ------
>> *From:* dev-boun...@lists.openshift.redhat.com [
>> dev-boun...@lists.openshift.redhat.com] on behalf of Jordan Liggitt [
>> jligg...@redhat.com]
>> *Sent:* Thursday, April 14, 2016 9:16 AM
>> *To:* Chmouel Boudjnah
>> *Cc:* OpenShift List Dev
>> *Subject:* Re: keystonepasswd auth
>>
>> The OpenShift Keystone IDP integration only supports the v3 Keystone API.
>> I don't see any discussion of tenants in the doc for that API (
>> http://developer.openstack.org/api-ref-identity-v3.html)
>>
>>
>>
>> On Thu, Apr 14, 2016 at 12:06 PM, Chmouel Boudjnah 
>> wrote:
>>
>>> Hello,
>>>
>>> I was looking at trying the keystone password authentication. While
>>> there is some missing directive in the documentation :
>>>
>>> https://github.com/openshift/openshift-docs/pull/1902
>>>
>>> things are working and i could properly auth my openshift user with my
>>> keystone username/password.
>>>
>>> The only caveat is that in OpenStack we usually need to specify a
>>> tenant_name/id for the user to auth with, by default if I understand
>>> correctly gophercloud would try to match the provider from the argument
>>> provided :
>>>
>>>
>>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/auth_options.go#L10-L11
>>>
>>> which in this case if no tenant_name are specified would do a
>>> tenant_name==user_name like done by default on Rackspace Cloud (gophercloud
>>> is written by rackspace)
>>>
>>> So now the question is how can we improve this and be able to specify a
>>> tenant_name in there? Since most of deployed OpenStack clouds would have
>>> multiple users scoped to different tenants
>>>
>>> We could do some hackery things like having a delimiter like colon : to
>>> be able to split those as tenant_name and user_name which is something we
>>> did on swiftclient sometime ago but that's not very openstackish and was
>>> more of hack that need to be supported forever (i implemented that :(( )
>>>
>>> We could add a switch like --keystone-tenant-name or something but i
>>> guess that would pollute the login if we want to add more stuff.
>>>
>>> Maybe using the openstack environment which is a standard way in
>>> OpenStack for the clients to use would be an option :
>>>
>>>
>>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/openstack/auth_env.go#L24
>>>
>>> which would be transparent for the user since they would have only to
>>> download their openrc from openstack dashboard (horizon) and just issue a
>>> oc login to connect (which could be only a fallback to the current method)
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Chmouel
>>>
>>>
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: keystonepasswd auth

[Jordan Liggitt]

I'm not seeing where tenant name is defaulted to the user name. The
keystone auth request is a password authentication with the user name and
domain name, which uniquely identifies the user (users belong to domains,
not tenants/projects)

On Thu, Apr 14, 2016 at 12:20 PM, Fox, Kevin M  wrote:

> keystone v3 renamed tenant to project. Otherwise, should be the same.
>
> Thanks,
> Kevin
>
>
> --
> *From:* dev-boun...@lists.openshift.redhat.com [
> dev-boun...@lists.openshift.redhat.com] on behalf of Jordan Liggitt [
> jligg...@redhat.com]
> *Sent:* Thursday, April 14, 2016 9:16 AM
> *To:* Chmouel Boudjnah
> *Cc:* OpenShift List Dev
> *Subject:* Re: keystonepasswd auth
>
> The OpenShift Keystone IDP integration only supports the v3 Keystone API.
> I don't see any discussion of tenants in the doc for that API (
> http://developer.openstack.org/api-ref-identity-v3.html)
>
>
>
> On Thu, Apr 14, 2016 at 12:06 PM, Chmouel Boudjnah 
> wrote:
>
>> Hello,
>>
>> I was looking at trying the keystone password authentication. While there
>> is some missing directive in the documentation :
>>
>> https://github.com/openshift/openshift-docs/pull/1902
>>
>> things are working and i could properly auth my openshift user with my
>> keystone username/password.
>>
>> The only caveat is that in OpenStack we usually need to specify a
>> tenant_name/id for the user to auth with, by default if I understand
>> correctly gophercloud would try to match the provider from the argument
>> provided :
>>
>>
>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/auth_options.go#L10-L11
>>
>> which in this case if no tenant_name are specified would do a
>> tenant_name==user_name like done by default on Rackspace Cloud (gophercloud
>> is written by rackspace)
>>
>> So now the question is how can we improve this and be able to specify a
>> tenant_name in there? Since most of deployed OpenStack clouds would have
>> multiple users scoped to different tenants
>>
>> We could do some hackery things like having a delimiter like colon : to
>> be able to split those as tenant_name and user_name which is something we
>> did on swiftclient sometime ago but that's not very openstackish and was
>> more of hack that need to be supported forever (i implemented that :(( )
>>
>> We could add a switch like --keystone-tenant-name or something but i
>> guess that would pollute the login if we want to add more stuff.
>>
>> Maybe using the openstack environment which is a standard way in
>> OpenStack for the clients to use would be an option :
>>
>>
>> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/openstack/auth_env.go#L24
>>
>> which would be transparent for the user since they would have only to
>> download their openrc from openstack dashboard (horizon) and just issue a
>> oc login to connect (which could be only a fallback to the current method)
>>
>> What do you think?
>>
>> Cheers,
>> Chmouel
>>
>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: keystonepasswd auth

[Jordan Liggitt]

The OpenShift Keystone IDP integration only supports the v3 Keystone API. I
don't see any discussion of tenants in the doc for that API (
http://developer.openstack.org/api-ref-identity-v3.html)



On Thu, Apr 14, 2016 at 12:06 PM, Chmouel Boudjnah 
wrote:

> Hello,
>
> I was looking at trying the keystone password authentication. While there
> is some missing directive in the documentation :
>
> https://github.com/openshift/openshift-docs/pull/1902
>
> things are working and i could properly auth my openshift user with my
> keystone username/password.
>
> The only caveat is that in OpenStack we usually need to specify a
> tenant_name/id for the user to auth with, by default if I understand
> correctly gophercloud would try to match the provider from the argument
> provided :
>
>
> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/auth_options.go#L10-L11
>
> which in this case if no tenant_name are specified would do a
> tenant_name==user_name like done by default on Rackspace Cloud (gophercloud
> is written by rackspace)
>
> So now the question is how can we improve this and be able to specify a
> tenant_name in there? Since most of deployed OpenStack clouds would have
> multiple users scoped to different tenants
>
> We could do some hackery things like having a delimiter like colon : to be
> able to split those as tenant_name and user_name which is something we did
> on swiftclient sometime ago but that's not very openstackish and was more
> of hack that need to be supported forever (i implemented that :(( )
>
> We could add a switch like --keystone-tenant-name or something but i guess
> that would pollute the login if we want to add more stuff.
>
> Maybe using the openstack environment which is a standard way in OpenStack
> for the clients to use would be an option :
>
>
> https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/openstack/auth_env.go#L24
>
> which would be transparent for the user since they would have only to
> download their openrc from openstack dashboard (horizon) and just issue a
> oc login to connect (which could be only a fallback to the current method)
>
> What do you think?
>
> Cheers,
> Chmouel
>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Get project members

[Jordan Liggitt]

`oc get rolebindings` will list the users and groups bound to roles in
the project



> On Mar 25, 2016, at 2:02 PM, Brandon Richins  
> wrote:
>
> I’m trying to find a way to list project members.  I’ve looked at `oc get 
> policy` clusterpolicy, clusterpolicybinding, etc.  I just can’t seem to find 
> what I’m after.  I’m looking to find any non-system user and list their role. 
>  Like jim: basic-user, bob: admin, etc.
>
> Any ideas?
>
> Brandon Richins
>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: file parameters

[Jordan Liggitt]

The UI can certainly do that (it already has file inputs in other forms). A
presentation hint would be helpful for the template author to be able to
express (text field, multi-line textbox, or file input)... it would look
awful for every field to have a "single/multi/file" toggle beside it.

On Thu, Feb 25, 2016 at 6:10 PM, Ben Parees  wrote:

> I wouldn't expect the template format itself to support a file reference,
> but having the UI support some sort of "upload from file" option for
> filling in a parameter value seems more likely (though still not super
> likely).  Will leave it to the UI team to comment on the likelihood of such
> a feature.
>
> (I would have similar expectations regarding having the template
> instantiation CLI support supplying a parameter value from a local file)
>
>
> On Thu, Feb 25, 2016 at 5:35 PM, Philippe Lafoucrière <
> philippe.lafoucri...@tech-angels.com> wrote:
>
>> Hi Guys,
>>
>> I wonder if having a file parameter in template would be added to the
>> roadmap.
>> My point: a deployer template where I can pass directly certificates and
>> keys as files. The main difference would be in the UI, where the field
>> would be a file input, instead a text input.
>>
>> Thanks,
>> Philippe
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Unable to get api token using oauth2 gem

[Jordan Liggitt]

Do you have any debug logs or details about how you are setting up the
request for the authorization code, and the follow up request for the
access token?

On Wed, Jan 20, 2016 at 10:17 AM, phijo joseph  wrote:

> Hi ,
>
> I am currently trying to integrate openshift with my ruby application.
> When i try to get api token using curl, I'm able get the token. But when I
> tried to get the token using OAuth2 gem,
> it is not working as expected. I'm getting an error as follows.
>
> OAuth2::Error: invalid_grant: The provided authorization grant (e.g.,
> authorization code, resource owner credentials) or refresh token is
> invalid, expired, revoked, does not match the redirection URI used in the
> authorization request, or was issued to another client.
> {"error":"invalid_grant","error_description":"The provided authorization
> grant (e.g., authorization code, resource owner credentials) or refresh
> token is invalid, expired, revoked, does not match the redirection URI used
> in the authorization request, or was issued to another client."}
>
> I am not sure am i right, As I am very new to OAuth concept. It will be
> great if someone can guide me to use OAuth on openshift Origin v3
>
> I would like to know where can i see my authorize token.
>
> Regards
> Phijo
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev