[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Authorization rules will soon be tightened



You could do it similar to the way that we handle multi-node vagrant configurations today.  You can create a persistent volume for your cert-dir, mount that persistent volume in the correct location for your docker container and then use that persistent volume to retrieve the generated certs for client access.  I wouldn't consider it a long term solution, but it's probably the simplest way to do it today.

Long term, we're going to want to make use of secrets to pass auth information into a pod.

On Tue, 2015-02-24 at 13:40 -0500, Derek Carr wrote:
What is the best way I can get a kubeconfig that is minted on openshift start when I am running inside a docker container to use by a client?


Or a pod on Kubernetes?

Sent from my iPhone

On Feb 24, 2015, at 8:56 AM, David Eads <deads redhat com> wrote:


Up until now, authorization rules have been enforced, but the bootstrap bindings themselves have been very permissive.  All authenticated and unauthenticated users were granted all permissions on all projects.

Once https://github.com/openshift/origin/pull/1074 is merged, the bootstrap rules will not allow unauthenticated users to perform any actions on any resources.  When openshift starts up, a client certificate is created for a user called "system:admin".  The bootstrap policy grants all permissions on all projects to system:admin.  That user identity can be used from the command line by running
    export KUBECONFIG="`pwd`/openshift.local.certificates/admin/.kubeconfig"
Setting that environment variable tells osc to use that .kubeconfig file which includes the client certificate for system:admin.

In order to use the web console, you'll need to grant permissions to your user (whatever name you chose).  You can do that with a command like this, run by system:admin:
    openshift ex policy add-user --namespace=your-project view anypassword:test-admin
That command grants view permission to the user "test-admin".  With that permission, "test-admin" will see the default project in the web console.

If you want to create a new project, there's a convenience command that will create the project and grant a user admin rights to the project at the same time.
    openshift ex new-project test --display-name="OpenShift 3 Sample" --description="This is an example project to demonstrate OpenShift v3" --admin=anypassword:test-admin
That command will create a new project called "test", that shows up as "OpenShift 3 Sample" in the web console, and grants the user test-admin administrative rights to the project.

The new bootstrap bindings will only be created if you start openshift against an empty etcd.  If you need to report a problem related to authorization, please include the name of the user you're using and the output from the following commands:
    osc describe policy default --namespace=master
    osc describe policybindings master --namespace=master
    osc describe policy default --namespace=the-project-you're-accessing
    osc describe policybindings master --namespace=the-project-you're-accessing
    osc describe policybindings the-project-you're-accessing --namespace=the-project-you're-accessing

Those commands provide a listing of all the policy bindings, roles, and rules that are being applied and that will help with issue reproduction and diagnosis.

For a more in-depth discussion of how authorization rules work and additional details and examples of commands, see the online documentation: http://docs.openshift.org/latest/using_openshift/authorization.html.
_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]