Hardcoded here

Looks like can be a maximum of 12 hours

Just wanted to note this boto3 alternative https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts/client/assume_role_with_web_identity.html

# Get Temporary AWS Credentials on CryoCloud JupyterHub
client = boto3.client('sts')

with open(os.environ['AWS_WEB_IDENTITY_TOKEN_FILE']) as f:
    TOKEN = f.read()

response = client.assume_role_with_web_identity(
    RoleArn=os.environ['AWS_ROLE_ARN'],
    RoleSessionName=os.environ['JUPYTERHUB_CLIENT_ID'],
    WebIdentityToken=TOKEN,
    DurationSeconds=3600
)

ACCESS_KEY_ID = response['Credentials']['AccessKeyId']
SECRET_ACCESS_KEY_ID = response['Credentials']['SecretAccessKey']
SESSION_TOKEN = response['Credentials']['SessionToken']

@scottyhq @yuvipanda this project is a jupyter_server / notebook extension that is serving a purpose for jupyterhub in cloud environments (currently only AWS) where cloud provider specific credentials are provided to the user servers, allowing them to work against object storage for example.

I think this could be in scope to maintain within the jupyterhub github organization, and I would be a jupyterhub org member willing to champion an adoption to it help maintain this project long term from within the organization. This project is of direct relevance for hubs deployed by 2i2c.org where I work, but its also relevant for the broader jupyterhub community just like for example https://github.com/jupyterhub/gh-scoped-creds that has also been adopted from Yuvi to the jupyterhub organization.

Technical roadmap

• Provide sphinx based documentation to cover
  • What the project is about
  • How it works
  • Security aspects
  • Admin user instructions (someone setting this up)
  • End user instructions (someone using this)
  • Changelog
• Add support for GCP credentials
• Add test of at least the extension setup
• Setup CI/CD for autoformatting, tests, and release automation
• Publish docs to readthedocs
• Publish package to PyPI

Question

@scottyhq @yuvipanda are you okay with letting this be adopted by jupyterhub, and that I would go ahead and ask about if jupyterhub is willing to adopt this project in jupyterhub/team-compass?

It could be nice to have some endpoint that can be called, like /api/jupyter-cloud-creds (without /aws in the end) that emits version info for example.

One key benefit is that we would have a basic way to test the server extension that didn't involve using the aws or gcloud CLI's.

I think any errors calling aws the CLI will result in a 200 response that writes out the stderr output.

We should:

1. Provide a non-2xx HTTP response status code if something goes wrong, probably something on 5xx as it relates to things happening on the server
2. Provide a nice response specifically for when aws or gcloud is not available, perhaps with the 501 Not Implemented error code

so far this is was only tested locally with running jupyter server then going to http://127.0.0.1:8889/api/cloudcreds/aws which worked!

cc @yuvipanda

I'm considering a name chance along with #4.

Let's breakdown the current name jupyter-cloud-scoped-creds:

1. jupyter because its exposing the creds through a jupyter server (jupyter_server or notebook)
   Perfect!
2. cloud and creds because it relates to extracting cloud providers' credentials
   Perfect!
3. scoped
   I guess the name jupyter-cloud-scoped-creds was inspired by gh-scoped-creds, but I think the scoped part doesn't translate to this project well. In gh-scoped-creds, the project enables a github users permissions provided to be reduced in scope to only a repository etc, but in this project we just expose all the available credentials to various cloud providers - they are not scoped to something specific by this project.

This project does ensre that the crendeitlas are temporary, and this project can the expiry time to some degree. I think adding temp or temporary to the name would be a bit much though, and that it could be sufficient to document this clearly and not include in the name.

Proposals

1. A project name change to jupyter-cloud-creds (from jupyter-cloud-scoped-creds)
2. An endpoint name change to api/jupyter-cloud-creds/aws (from api/cloudcreds/aws)
   If the endpoint name includes this projects name, it becomes easier for users to understand directly that this project provided the endpoint. Consider for example a server admin or similar sees request to api/jupyter-cloud-creds/aws in some logs, then it would be easier for them to find their way to this project and learn more than if it was api/cloudcreds/aws.

@scottyhq and @yuvipanda what do you think?

Currently things only work for AWS as noted in the readme