Giter Club home page Giter Club logo

otc-auth's Introduction

OTC-Auth

Open Source CLI for the Authorization with the Open Telekom Cloud.

License: GPLv3 Build Go Report Card CodeQL ViewCount

With this CLI you can log in to the OTC through its Identity Access Manager (IAM) or through an external Identity Provider (IdP) in order to get an unscoped token. The allowed protocols for IdP login are SAML and OIDC. When logging in directly with Telekom's IAM it is also possible to use Multi-Factor Authentication (MFA) in the process.

After you have retrieved an unscoped token, you can use it to get a list of the clusters in a project from the Cloud Container Engine (CCE) and also get the remote kube config file and merge with your local file.

This tool can also be used to manage (create) a pair of Access Key/ Secret Key in order to make requests more secure.

Table of contents

Demo

Login.OTC.via.IdP.OIDC.2.mp4

Install

Linux/BSD/Unix

We have repos set up for Arch, Debian, Fedora and Alpine.

Alternatively, you can download and use the binaries from our releases page. Remember to add it to your PATH! Replace {OTC_AUTH_VERSION} and {YOUR_PLATFORM} in the example below with the version you want to download and the platform you want to download it for.

curl -OL https://github.com/iits-consulting/otc-auth/releases/download/{OTC_AUTH_VERSION}/otc-auth_{YOUR_PLATFORM}.tar.gz
tar -xf otc-auth_{YOUR_PLATFORM}.tar.gz
sudo mv otc-auth /usr/local/bin/otc-auth                                                                                                                                                                                                                                                                            1

MacOS

We recommend using our brew tap to install otc-auth.

brew tap iits-consulting/homebrew-tap
brew install otc-auth

If you don't want to use brew, feel free to download the binary for your system from the releases page. Remember to add it to your PATH!

Windows/Other

Download the binary for your system from the releases page. Unpack the binary, add it to your PATH and you are good to go!

Login

Use the login command to retrieve an unscoped token either by logging in directly with the Service Provider or through an IdP. You can see the help page by entering login --help or login -h. There are three log in options (iam, idp-saml, and idp-oidc) and one of them must be provided.

Service Provider Login (IAM)

To log in directly with the Open Telekom Cloud's IAM, you will have to supply the domain name you're attempting to log in to (usually starting with "OTC-EU", following the region and a longer identifier), your username and password.

otc-auth login iam --os-username <username> --os-password <password> --os-domain-name <domain_name> --region <region>

Additionally, it is possible to use MFA if needed. In this case, both arguments --os-user-domain-id and --totp, are required (with --os-user-domain-id replacing --os-username). The user id can be obtained in the "My Credentials" page on the OTC.

otc-auth login iam --os-password <password> --os-domain-name <domain_name> --os-user-domain-id <user_domain_id> --totp <6_digit_token> --region <region>

The OTP Token is 6-digits long and refreshes every 30 seconds. For more information on MFA please refer to the OTC's documentation.

Identity Provider Login (IdP)

You can log in with an external IdP using either the saml or the oidc protocols. In both cases you will need to specify the authorization URL, the name of the Identity Provider (as set on the OTC), as well as username and password for the SAML login and client id (and optionally client secret) for the OIDC login flow.

External IdP and SAML

The SAML login flow is SP initiated and requires you to send username and password to the SP. The SP then authorizes you with the configured IdP and returns either an unscoped token or an error, if the user is not allowed to log in.

otc-auth login idp-saml --os-username <username> --os-password <password> --idp-name <idp_name> --idp-url <authorization_url> --os-domain-name <os_domain_name> --region <region>

At the moment, no MFA is supported for this login flow.

External IdP and OIDC

The OIDC login flow is user initiated and will open a browser window with the IdP's authorization URL for the user to log in as desired. This flow does support MFA (this requires it to be configured on the IdP). After being successfully authenticated with the IdP, the SP will be contacted with the corresponding credentials and will return either an unscoped token or an error, if the user is not allowed to log in.

otc-auth login idp-oidc --idp-name <idp_name> --idp-url <authorization_url> --client-id <client_id> --os-domain-name <os_domain_name> --region <region> [--client-secret <client_secret>]

The argument --client-id is required, but the argument --client-secret is only needed if configured on the IdP.

Service Account via external IdP and OIDC

If you have set up your IdP to provide service accounts then you can utilize service account with otc-auth too. Make also sure that the IdP is correctly configured in the OTC Identity and Access Management. Then run the otc-auth as follows:

otc-auth login idp-oidc \
    --idp-name NameOfClientInIdp \
    --idp-url IdpAuthUrl \
    --os-domain-name YourDomainName \
    --region YourRegion \
    --client-id NameOfIdpInOtcIam \
    --client-secret ClientSecretForTheClientInIdp \
    --service-account

OIDC Scopes

The OIDC scopes can be configured if required. To do so simply provide one of the following two when logging in with idp-oidc:

  • provide the flag --oidc-scopes pleasePut,HereAll,YourScopes,WhichYouNeed
  • provide the environment variable export OIDC_SCOPES="pleasePut,HereAll,YourScopes,WhichYouNeed"

The default value is openid,profile,roles,name,groups,email

Remove Login

Clouds are differentiated by their identifier --os-domain-name. To delete a cloud, use the remove command.

otc-auth login remove --os-domain-name <os_domain_name> --region <region>

List Projects

It is possible to get a list of all projects in the current cloud. For that, use the following command.

otc-auth projects list

Cloud Container Engine

Use the cce command to retrieve a list of available clusters in your project and/or get the remote kube configuration file. You can see the help page by entering cce --help or cce -h.

To retrieve a list of clusters for a project use the following command. The project name will be checked against the ones in the cloud at the moment of the request. If the desired project isn't found, you will receive an error message.

otc-auth cce list --os-domain-name <os_domain_name> --region <region> --os-project-name <project_name>

To retrieve the remote kube configuration file (and merge it to your local one) use the following command:

otc-auth cce get-kube-config --os-domain-name <os_domain_name> --region <region> --os-project-name <project_name> --cluster <cluster_name>

You could also pass the --days-valid argument to set the period of days the configuration will be valid for, with the default being 7 days. The -s or --server argument could also be used to override the server attribute in the config generated.

Manage Access Key and Secret Key Pair

You can use the OTC-Auth tool to download permanent AK/SK pairs directly from the OTC. A file called "ak-sk-env.sh" will be created in the current directory. The file contains four environment variables.

otc-auth access-token create --os-domain-name <os_domain_name> --region <region>

If a temporary AK/SK pair is needed instead, use the following command:

otc-auth temp-access-token create --os-domain-name <os_domain_name> --region <region> -t <lifetime in seconds>

This will generate a temporary AK/SK pair (valid for 15m by default, if the -t argument is not given), saved to " ak-sk-env.sh". The file will contain five environment variables.

The "ak-sk-env.sh" file must then be source-ed before you can start using the environment variables.

Openstack Integration

The OTC-Auth tool is able to generate the clouds.yaml config file for openstack. With this file it is possible to reuse the clouds.yaml with terraform.

If you execute this command

otc-auth openstack config-create

It will create a cloud config for every project which you have access to and generate a scoped token. After that it overrides the clouds.yaml (by default: ~/.config/openstack/clouds.yaml) file.

Environment Variables

The OTC-Auth tool also provides environment variables for all the required arguments. For the sake of compatibility, they are aligned with the Open Stack environment variables (starting with OS).

Environment Variable Argument Short Description
CLIENT_ID --client-id c Client id as configured on the IdP
CLIENT_SECRET --client-secret s Client secret as configured on the IdP
CLUSTER_NAME --cluster c Cluster name on the OTC
OS_DOMAIN_NAME --os-domain-name d Domain Name from OTC Tenant
REGION --region r Region code for the cloud (eu-de for example)
OS_PASSWORD --os-password p Password (iam or idp)
OS_PROJECT_NAME --os-project-name p Project name on the OTC
OS_USER_DOMAIN_ID --os-user-domain-id i User id from OTC Tenant
OS_USERNAME --os-username u Username (iam or idp)
IDP_NAME --idp-name i Identity Provider name (as configured on OTC)
IDP_URL --idp-url N/A Authorization endpoint on the IDP
SKIP_TLS_VERIFICATION --skip-tls-verification N/A Skips TLS Verification

Auto-Completions

You install the auto completions for your shell by running. Please follow the instructions by running otc-auth completion --help in your terminal.

Debugging

Is something not working the way you've expected? otc-auth uses glog for logging with all info output at log-level 1. In the following example, we'd like to have the logs from the OIDC login command be saved to our current directory:

otc-auth login idp-oidc -v 1 --log_dir .

We could also just print the logs to stderr instead of writing them to a file:

otc-auth login idp-oidc -v 1 --logtostderr=true

The more advanced logging features (like logging to both a file and stderr, emitting a stack trace at a specific line, buffering log messages and more) are described in the glog documentation.

otc-auth's People

Contributors

behoof4mind avatar dependabot[bot] avatar dombisza avatar jotabe87 avatar mattiascockburn avatar ninja243 avatar zeljkobekcic avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

otc-auth's Issues

Error during login leads to two active clouds

The login process sets a cloud to active too early on and/or does not remove it or set to inactive if an error occurs. That leads to having 2 active clouds at a given moment, which is unwanted behavior (and otc-auth won't work).

Steps to reproduce: login to one cloud and break the process in the middle (either by not logging in properly on oidc, or something else). Login to another cloud and you will see the error.

Permission denied after upgrade to 2.0.7

Hey,

we updated from Verison 2.0.0 to Version 2.0.7 and now do get the following error message:

2023/10/23 10:15:02 info: cloud config created
2023/10/23 10:15:02 Cloud OTCXXXXXXXX loaded successfully and set to active.
2023/10/23 10:15:02 Retrieving unscoped token for active cloud...
2023/10/23 10:15:05 error: status 403 Forbidden, body:
{"error":{"code":403,"message":"You are not authorized to perform the requested action.","title":"Forbidden"}}
2023/10/23 10:15:05 fatal: response failed with status 403 Forbidden. Body:
{
   "error": {
      "code": 403,
      "message": "You are not authorized to perform the requested action.",
      "title": "Forbidden"
   }
}
2023/10/23 10:15:05 Cloud OTCXXXXXXXX loaded successfully and set to active.
2023/10/23 10:15:05 fatal: no valid unscoped token found.

Please obtain an unscoped token by logging in first

We do not see any breaking changes in the changelog nor does the version number indicate any. We are using the command: otc-auth login idp-oidc and the following env vars (no command line arguments):

export CLIENT_ID
export CLIENT_SECRET
export IDP_URL
export OIDC_SCOPES="profile,openid,email"
export CLUSTER_NAME
export OS_DOMAIN_NAME
export REGION
export OS_PROJECT_NAME
export IDP_NAME

Are there any changes that we missed?

Thanks and best regards,
Björn

Support service accounts for OIDC

Currently for OIDC we only allow webbrowser based logins.

It would be nice if we could also support service account logins (for example for gitlab runners).

AK/SK Generation does not work properly

Currently we create a temporary AK/SK but the problem is that with the temporary AK/SK you also need the timestamp and the security token everytime you want to use the temp AK/SK.

This is to complicated.

We should switch to permanent AK/SK Generation. With should have 2 options "create/delete" we can make use of the description field in the API. That means we only create 1 AK/SK everytime. If there is already a AK/SK for the user we don't create one and give back the existing one.

I would suggest as the identifier we take the description field with the value "otc-auth".

Since it is a permanent one we also need the option to delete the AK/SK

Installation via package managers

I would like to be able to install it with brew on the macos.

  • Brew for MacOS
  • APT for Debian based distros
  • RPM for redhat based distros
  • AUR for archlinux based distros
  • more to be added

create-kube-config command doesn't automatically request a scoped token

When getting a kube config from the otc using the create-kube-config command it won't automatically request a scoped token if one isn't available for the current project.

In kube-config.go:

func getKubeConfig(kubeConfigParams KubeConfigParams) string {
    //  check for scoped token before this call
    response := getClusterCertFromServiceProvider(kubeConfigParams.ProjectName, clusterId, kubeConfigParams.DaysValid)
}

The scoped token should be available before the call in the getClusterCertFromServiceProvider function:

func getClusterCertFromServiceProvider(projectName string, clusterId string, duration string) (response *http.Response) {
    // project.ScopedToken should not be empty here
    request.Header.Add(xheaders.XAuthToken, project.ScopedToken.Secret)
}

otc-auth openstack config-create broken

Version: OTC-Auth 2.0.0 (2023-06-09T16:06:28Z

otc-auth openstack config-create --region eu-de
Results in:
unknown arguments --region eu-de

otc-auth openstack config-create
-> fatal: --region not provided.

Please make sure the argument --region is provided or the environment variable REGION is set.

That doesn't seem right.

empty region supplied, can't generate IAM URL

Hello,

I have created an IdP with SAML at OTC for our Azure AD connection.

I then try to use the otc-auth cli with this arguments:

otc-auth login idp-saml --os-username <username_from_AD> --os-password <password_from_AD> --idp-name <idp_name_from_OTC> --idp-url <authorization_url_from_AD> --os-domain-name <os_domain_name> --region eu-de

But then I got this error:

Cloud OTC00000000001000096611 loaded successfully and set to active.
Retrieving unscoped token for active cloud...
fatal: empty region supplied, can't generate IAM URL

What is wrong with my arguments?

Best regards, Jens

Endpoints are hard coded

Currently the endpoints are hardcoded like this:

baseUrlIam = "https://iam.eu-de.otc.t-systems.com:443"
baseUrlCce = "https://cce.eu-de.otc.t-systems.com:443"
protocols  = "protocols"
auth       = "auth"

This brings the problem that it only works for eu-de

Support setting the kubeconfig file to a different location

Hi,

the usage of kubectx or different kubeconfig contexts is sometimes dangerous so we do use different kubeconfig files for different environments. Would it be possible to implement a commandline argument to overwrite the kubeconfig target location?

Like

--kubeconfig /my/own/kube.config

Thanks and kind regards
Björn

Requesting scoped token on login leads to loop

When logging in, otc auth requests a scoped token right away (doesn't seem to be wanted behavior), and it does that in a loop:

image

We should fix it to request scoped tokens only when necessary, and only once.

Update commands on README

Right now the commands on the README File are outdated. They should be updated to reflect the fact that most of them need a --os-domain-name argument

Error login: Exactly one of Username and UserID must be provided

Setup

  • MacBook Pro M3 Pro
  • macOS Sonoma 14.2.1
  • otc-auth 2.0.9 (via homebrew)

Actual Behavior

Since 2.0.0 (that is why I didn't upgrade back then) I cannot login via Service Provider Login (IAM)

otc-auth login iam --os-username <username> --os-password <password> --os-domain-name <domain_name> --os-user-domain-id <user_domain_id> --totp <6_digit_token> --region <region>

As soon as I provide --totp for MFA I have to provide all of the parameters above. All variables are properly exported / env variables.

otc-auth login iam --overwrite-token --totp xxxxxx                                                                                                                                                                                                                                                 
2024/01/02 17:35:02 info: cloud OTC-xx-yy-zzzzzzzzzzzzzzzz loaded successfully and set to active.
2024/01/02 17:35:02 info: retrieving unscoped token for active cloud...
2024/01/02 17:35:02 error extracting token: Exactly one of Username and UserID must be provided for password authentication

As soon as I unset one of Username or UserID, I get the following messages:

otc-auth login iam --overwrite-token --totp xxxxxx                                                                                                                                                                                                                                                   
Error: required flag(s) "os-username" not set

or:

otc-auth login iam --overwrite-token --totp xxxxxx                                                                                                                                                                                                                                                   
Error: if any flags in the group [totp os-user-domain-id] are set they must all be set; missing [os-user-domain-id]

Expected Behavior

Using the latest version I can login via otc-auth login iam --totp.

print kubeconfig to stdout

Instead of merging a desired kubeconfig automatically, I would like to have it printed to stdout. This allows otc-auth's usage in a terraform k8s/helm provider for example.

Problem with secu_admin role is not inside the scoped token for eu_de

I discovered when you use the terraform with the top level project like this:

provider "opentelekomcloud" {
  cloud = "${var.os_domain_name}_${var.region}_${var.context}"
}

module "vaultkeys_bucket" {
  source      = "registry.terraform.io/iits-consulting/project-factory/opentelekomcloud//modules/obs_restricted"
  version     = "5.4.0"
  bucket_name = "${var.context}-${var.stage}-vaultkeys"
  providers   = {
    opentelekomcloud = opentelekomcloud.top_level_project
  }
  tags = local.tags
}

I will give some error since the scoped token for eu-de does not include the secu_admin role.

If i use the unscoped token it works but i get problems with KMS Key creation.
If i use AK/SK everything works perfect.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.