OpenShift (Cloud) Pod STATUS: Crash Loop Back-off,changing ownership not permitted - authentication

I created an application on existent OpenShift project by pulling a docker image from remote repo.
The pod is created but fails with STATUS "Crash Loop Back-off".
Invesitgating the reason using
oc log <pod id> -p
it appears a list of unsuccessfull "chown: changing ownership of '...': Operation not permitted
I found this is due to non predictable user id running the container.
According to
https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html and various post here and there,
it seems the solution is to relax security policy:
oc login -u system:admin https://<remote openshift endpoint>
oadm policy add-scc-to-group anyuid system:authenticated
If this is the solution, I don't know, because I cannot get out of 1st problem:
oc login -u system:admin
asks for login/pwd and after print an error
error: username system:admin is invalid for basic auth
I guess there is the need of a certificate, a token, something secure, but I cannot understand how to generate it from Openshift, or
if there was a key pair to generate locally (of which kind) and how to bind the key to the user. Furthermore, checking in the web console
I cannot see that kind of user (system:admin).
Am I missing something?
Thanks a lot,
Lorenzo

Related

Able to authenticate with SSH with Github but somehow says "key is already in use"?

I have two ssh keys i've created, first one for my personal use and
the second one which I just created for work/school.
When I log into using git CLI using SSH with the second SSH key, it says
that i have successfully logged in like below
$ winpty gh auth login
? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations? SSH
? Upload your SSH public key to your GitHub account? C:\Users\dykim\.ssh\id_rsa.
pub
? Title for your SSH key: (GitHub CLI) second-key
? Title for your SSH key: future_proof
? How would you like to authenticate GitHub CLI? Login with a web browser
! First copy your one-time code: 0B1D-6370
Press Enter to open github.com in your browser...
✓ Authentication complete.
- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
HTTP 422: Validation Failed (https://api.github.com/user/keys)
key is already in use
so somehow there isn't a problem to authenticating.
But I am worried that this will somehow pop up later and be a problem later when I am
working on my future projects for work.
What can I do to avoid this issue?
That seems similar to a pending reported issue #5299: "Spurious auth error when SSH key is already registered on account"
Steps to reproduce the behavior
Run gh auth login and select an SSH key that is already registered with the account
Get the above error, even though the key will work correctly
Expected vs actual behavior
I think there are a couple of ways that the handling of already registered keys could be improved:
Given the CLI app is granted full permission over the user's registered SSH keys, it could presumably list the already registered ones first and only attempt to register a new key if it wasn't already registered.
Then the error would only occur if the key was registered on a different account (or you uploaded it via the web browser while also attempting to register the CLI app, which would be an odd thing to do)
Customise the error message when this step fails to say something like "key already in use (Note: this error is expected if this SSH key was already registered on your account)"

gcloud instance in a project generates 403 error- for fast.ai setup

I'm trying to create an instance inside a project using the commands I've been given for setting things up for fastai using Ubuntu 2004 in windows 10.
gcloud compute instances create $INSTANCE_NAME \
--zone=$ZONE \
--image-family=$IMAGE_FAMILY \
--image-project=deeplearning-platform-release \
--maintenance-policy=TERMINATE \
--accelerator="type=nvidia-tesla-p100,count=1" \
--machine-type=$INSTANCE_TYPE \
--boot-disk-size=200GB \
--metadata="install-nvidia-driver=True" \
--preemptible
The above request creates an error:
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - The user does not have access to service account 'service-#############compute-system.iam.gserviceaccount.com'. User: 'emailaddress#gmail.com'. Ask a project owner to grant you the iam.serviceAccountUser role on the service account
I'm kind of surprised I don't have access, as on the iam page, my email address from emailaddress#gmail.com is the owner (edit: on the iam page my email address is listed as the owner). The active account through gcloud auth list is emailaddress#gmail.com. I tried adding --impersonate-service-account withservice-##########computer-system.iam.gserviceaccount to create the image, but that was [403] forbidden with explanation: Make sure the account that's trying to impersonate it has access to the service account itself and the "roles/iam.serviceAccountTokenCreator" role.
even from the https://cloud.google.com/ai-platform/deep-learning-vm/docs/cli page, these are expected parameters. I can create an image from https://console.cloud.google.com/home/ but I don't know how to modify the accelerator or a couple other settings
There is a warning it creates, but I am fairly certain how to solve this issue: found in the fast.ai forum files to add billing to the account. Only added for completeness since I haven't changed it yet.
WARNING: Some requests generated warnings: - Disk size: '200 GB' is larger than image size: '50 GB'. You might need to resize the root repartition manually if the operating system does not support automatic resizing. See https://cloud.google.com/compute/docs/disks/add-persistent-disk#resize_pd for details
edit in response to the comment:
Without the impersonation flag I received the same error.
With impersonating the #computer-system.iam.gservice I got:
ERROR: (gcloud.compute.instances.create) Error 403 (Forbidden) - failed to impersonate [service-392038697283#compute-system.iam.gserviceaccount.com]. Make sure the account that's trying to impersonate it has access to the service account itself and the "roles/iam.serviceAccountTokenCreator" role.
so I added the serviceAccountTokenCreator role to that and I got
ERROR: (gcloud.compute.instances.create) Error 403 (Forbidden) - failed to impersonate [service-392038697283#compute-system.iam.gserviceaccount.com]. Make sure the account that's trying to impersonate it has access to the service account itself and the "roles/iam.serviceAccountTokenCreator" role.
I'm giving these roles time limits as I think I just need to create the instance and that should be enough, but I'm unable to create the instance
edit: as of 09 July 2020, I tried installing Ubuntu 18.04from this FastAI forum thread which helped with a previous error but added nothing to the current issue. I tried going from wsl-2 to wsl-1 which also didn't work. While I would thoroughly suggest trying to suggestions in the comments I just went with a different service.

gcloud compute -- Instance ssh-key metadata ignored?

Starting with a service account JSON key, I attempt to add a throwaway "foo" ssh key to the gcloud instances create metadata and then connect to the instance using vanilla ssh and the throwaway key.
Script
here.
Expected behavior
At boot, the account daemon would create a user account corresponding to the supplied ssh key.
Observed behavior
In the Cloud Console, the instance shows correctly applied ssh metadata.
ssh -i throwaway_private_key foo#${IP} fails.
Logs on the instance show:
Apr 6 16:58:34 sshkey-test-x0rmqgh7 sshd[497]: Invalid user foo from 209.6.197.126 port 39792
How do I correctly trigger the account daemon?
If not through the metadata, then what?
Thanks!
For anyone struggling with a similar issue, there is a HUGE gotcha with os-login that can lead to the problem behavior.
In a nutshell, os-login="TRUE" can be (and is likely to be) set project-wide on GCE. If that's the case, then ssh-key metadata is ignored. I only discovered this by chance from reading other issues in the Google bug tracker.
As soon as I toggled os-login, my issue went away.

ERROR: (gcloud.compute.ssh) Could not fetch resource: - Insufficient Permission

I am having trouble working through the Compute Engine Quickstart: Build a to-do app with a MongoDB tutorial. (edit: I am running the tutorial from within the compute engine console; i.e. https://console.cloud.google.com/compute/instances?project=&tutorial=compute_quickstart)
I SSH into the backend instance. I enter the "gcloud compute" command as copied from the tutorial. I am prompted to enter a passphrase. The following is returned:
WARNING: The public SSH key file for gcloud does not exist.
WARNING: The private SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
...
<< Identifying detail ommitted >>
...
**ERROR: (gcloud.compute.ssh) Could not fetch resource:
- Insufficient Permission**
I had run through this stage of the tutorial on a previous occasion with no problems.
I am working from a Windows 10 PC with the google-cloud-sdk installed. I am using google chrome. I have tried in both regular and incognito modes.
Any help or advice greatfully received!
DaveDub
It looks like the attempt to SSH is recognising the instance in your project, but the user doesn't have the required permissions to access the machine.
Have you tried running:
gcloud auth login
and completing the web-based authorization to ensure you are attempting to access the machine as the correct (authenticated) user? This process ensures the Cloud SDK you are running inherits the permissions of the user specified in the web-based authorisation. See here for more information on this.
It's also worth adding the link to the tutorial you are following to your question.
Besides the accepted answer, be sure you are in the correct gcloud project
gcloud projects list
Then
gcloud config set project <your-project>
I just ran into this for yet another reason. Google has always had poor handling of multi-user auth conflicts with their business products. Whatever you sign into a clean chrome session with 'first' gets a 'special', invisible role. I've noticed with gsuite that I get 'forced' into that first user when I try to access the admin panel, and the only way to escape is to make sure that whatever google user I use for the gsuite admin is 'first', or open an incognito window. I've seen this bug for years, can't believe it still exists.
Anyways, I ran into a similar issue. Somehow I was the wrong google user, so the link I got when copy/pasting out of 'connect with gcloud command' was implying wrong google user. Only noticed later when I just gave up and used the terminal that I was not my normal user... So, might look into that.

Openshift Origin Latest Project creation issue

I am unable to create project in open shift. I created a project previously and deleted it. Looks like a project exists but unable to access or delete it. Seems like i am stuck. Also logging into the console https://console.preview.openshift.com/console/ doesn't show any existing projects.
I ran the following oc commands from the terminal.
Any suggestions on how to resolve this issue?
Thanks
XX:~ XX$ oc new-project test
Error from server: projectrequests "test" is forbidden: user XX cannot create more than 1 project(s).
XX:~ XX$ oc delete project test
Error from server: User "XX" cannot delete projects in project "test"
XX:~ XX$ oc status
Error from server: User "XX" cannot get projects in project "default"
XX:~ XX$ oc get projects
You need to give privileges/policies to your user which will allow the actions you want to perform.
If you are just in a proof-of-concept environment I would recommend the make your user cluster-admin in the whole cluster. This will give all the possible privileges to your user. Of course this in't recommended for every user in a 'real' environment.
First you need to authenticate with the 'default admin' which is created after the installation. This default admin-user isn't working with the normal user/password authentication. It's using a client certificate.
oc login -u system:admin --config=/etc/origin/master/admin.kubeconfig
Now you will see a list of the available projects (default, openshift management, etc). Now you're able to give cluster-roles to other users.
Make your user cluster-admin over the whole cluster
oadm policy add-cluster-role-to-user cluster-admin (youruser)
Now you have the cluster-admin privileges inside the whole cluster. You are also able to give privileges for some user in a specific project and not in the whole cluster. Than you have to use:
oadm policy add-role-to-user <role> <username> (in the current project)
This will give the role to a user, but only inside the project from where you've performed this command.
For more information about the avaiable cluster roles and policies I will point to the official documentation.
I raised a defect with Openshift Team as pointed out in the Support Link.
https://docs.openshift.com/online/getting_started/devpreview_faq.html#devpreview-faq-support
Here is the response i received from Support Team.
It seems that you have issued a bug and followed up for this already:
https://bugzilla.redhat.com/show_bug.cgi?id=1368862
After the cause is investigated, our operations team will sure clean up the project manually for you to allow you continue working with the developer preview
Latest update:
The project has now been cleaned up and you should be able to create a new project.
I am able to create Project in Openshift now.