Skip navigation

Blog Posts

Total : 4,720

Blog Posts

1 2 Previous Next

vSphere 7.0 U1 リリースにあわせて、

vSphere with Kubernetes が vSphere with Tanzu になりました。

VMware vSphere with Tanzu リリース ノート

 

そして、NSX-T なしでも Tanzu Kubernetes クラスタを作成できるようになったので、

さっそくラボ環境を構築してみました。

 

製品ドキュメントは下記です。

vSphere with Tanzu について

 

このうち、NSX-T ではなく vSphere ネットワーク(vDS)を利用する場合の要件は、

下記のあたりに説明があります。

vSphere ネットワークを使用して スーパーバイザー クラスタ を設定するためのシステム要件およびトポロジ

 

ドキュメント以外にも、まず動作する環境を用意したい場合は、

下記にある Quick Start Guide が参考になります。

https://core.vmware.com/resource/vsphere-tanzu-quick-start-guide

 

ちなみに、vSphere 7.0 GA 時点の時と同様に、NSX-T を利用した環境構築も可能です。

その様子についてはこちらもどうぞ。

vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。(NSX-T あり編)

 

手順の流れ。

今回は、下記のような流れで説明していきます。

  1. 前提とするラボ環境の説明。(vSphere 環境の構築については、今回は省略)
  2. HAProxy のデプロイ。
  3. 「ワークロード管理」の有効化。
  4. Tanzu Kubernetes クラスタの作成。

 

構成について。

ラボの構成イメージは、下記のような感じです。

「Ext GW」は各ネットワークのゲートウェイとなるルータです。

パラメータの事情説明などは、後続の手順にて・・・

Tanzu-HomeLab_2020-1026.png

 

vSphere Client での完成イメージは、下記のような感じです。

スーパーバイザー クラスタの名前空間、Tanzu Kubernetes クラスタを作成します。

それぞれ、スクリーンショットでは下記の名前です。

  • スーパーバイザー クラスタ: wcp-cluster-04
  • スーパーバイザー名前空間: lab-ns-41
  • Tanzu Kubernetes クラスタ: tanzu-cluster-41

tanzu-basic-01-11.png

 

今回の主なソフトウェア構成です。

  • vCenter Server 7.0 U1、仮想スイッチは vDS 7.0(NSX-T なし)
  • ESXi 7.0 U1
  • ロードバランサは HAProxy

 

前提環境の説明。

それでは、これからの vSphere with Tanzu 環境構築の前提とする、ラボ環境について説明します。

vSphere の構築については省略していますが、以前に紹介したものと同様にネステッド環境で構築しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)

 

vCenter 7.0 U1 に、ESXi 7.0 U1 (4台)のクラスタを構築してあります。

tanzu-basic-01-01.png

 

(今回の手順には関係しませんが)クラスタには 3台の vCLS VM が自動デプロイされています。

tanzu-basic-01-02.png

 

vSphere HA / DRS も有効化してあります。

tanzu-basic-01-07.png

 

仮想スイッチは、バージョン 7.0 の分散仮想スイッチ(vDS) です。

tanzu-basic-01-09.png

 

vDS には、vSphere with Tanzu で利用する 3種類のネットワークむけに、

それぞれ分散ポートグループを作成してあります。

  • 管理ネットワーク: DPortGroup-0010-MGMT、VLAN ID 10
  • ワークロード ネットワーク 1(プライマリ): DPortGroup-0021-WL1、VLAN ID 21
  • ワークロード ネットワーク 2: DPortGroup-0022-WL2、VLAN ID 22

そして物理ネットワークも、これらの VLAN での通信ができるように構成ずみです。

tanzu-basic-01-08.png

 

データストアには、vCenter の機能によるタグを割り当てずみです。

また、データストアに割り当てたタグを指定した、仮想マシン ストレージ ポリシーも作成ずみです。

これらは下記のように設定してます。

vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編

 

NFS データストアを、クラスタ内の全 ESXi ホストにマウントしてあります。

データストアには、タグ(タグ名は wcp-demo、カテゴリは datastore-category)を割り当ててあります。

tanzu-basic-01-03.png

 

データストアに割り当てたタグを指定した、仮想マシン ストレージ ポリシーも作成ずみです。

tanzu-basic-01-04.png

 

Tanzu Kubernetes Grid のコンテンツ ライブラリも作成ずみです。

以前は「ワークロード管理」有効化後に作成すればよかったのですが、

vSphere 7.0 U1 からは、事前作成が必要になりました。

コンテンツ ライブラリは下記のように作成しています。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

 

今回は、cl-tkg-01 という名前でコンテンツ ライブラリを作成しています。

tanzu-basic-01-05.png

 

Tanzu Kubernetes クラスタのノードとしてデプロイされる、OVF テンプレートがダウンロードされています。

複数の Kubernetes バージョンのものが用意されていることがわかります。

tanzu-basic-01-10.png

 

つづく。

How to set Goal in life and Why it is important to set Goal. What is the change comes in life by setting Goal. Today you will get the answer to every question.

   

Have you ever traveled When you travel somewhere, you have to take a ticket to where you have to go. If you go to the ticket counter and the ticket receptionist asks you where you want to go and you will say "nowhere", will you be able to go anywhere?

   

Similarly, if we want to get something in our life or to reach a destination, then we must first set up a goal of our life.

   

What is Goal?

   

Before setting the goal, let us know what the goal means. A goal is a predetermined task that a person tries to complete within a certain time frame. Different people set different goals in their life according to their wish, for example, if someone wants to become a cricketer, a singer a dancer or an artist.

   

Why It is Important to Set a Goal in Life:

 

 

Have you ever got a house built? Or ever seen a house being built? When we build a house, complete planning has to be done to get it built. If we do not do planning, then the structure of the house will become crooked.

   

The same thing applies to life too. If we do not plan about our life or do not set Goal, then our life will also become like a house without a proper structure. When we set goals in life, we know where we have to reach after a certain time and what we have to face to get there.

   

Psychology also says that people who have goals in their lives have the great enthusiasm in their lives and they are also more intelligent. People who have no goal in life, their lives are very boring and tasteless, they do not have any happiness in their lives and they always complain about their lives and blame others or their luck.

   

What to Do While Setting a Goal:

   

Friends, when we build a house, we plan everything where the bedroom should be, where should the kitchen be and in this way we prepare a complete map of the house and then decide how to decorate it. Similarly, while setting goals in our life, we also have to think a lot about various things. Let's see how we should set goals in our life.

   

Ask yourself some questions:

   

It is necessary to have a conversation with yourself before setting a goal. In this conversation, you have to ask yourself some questions such as what is the thing that you want to achieve within a set time period. And how long will it take to get that thing and what strategy has to be made, what challenges will come and how to deal with them. All these questions we have to ask ourselves before setting goals.

   

Create a road map:

   

The roadmap tells you what you need to do to reach a defined goal and what things you have to face. And you will also have to make a backup plan and if one of your plans fails, then you can switch to another plan. The roadmap will guide you to reach your goal. To create a roadmap, you can take help of someone who has already achieved the goal you want to achieve.

   

That person will tell you what the person did and what the challenges came to meet that goal and how he / she achieved that goal and you can also make your roadmap by following the same path. You can also take help of internet to create a roadmap.

   

Create weekly targets:

   

Small goals help you to reach big goals. If you make small weekly goals, then you will be able to achieve your big goals easily by the prescribed time period. And by setting goals every week, also make sure to observe your performance, for this you can take the help of weekly reports.

   

Follow the roadmap as much as possible:

   

The more you follow the roadmap, the greater your chances of being successful. To follow the roadmap successfully, you will have to put your 100% and this will be your biggest test.

   

Check your performance regularly:

   

Merely creating a road map and setting targets is not enough. We also have to observe and analyze the work we are doing regularly, which we can do by creating weekly reports. By making weekly reports, we can see if we are following the roadmap and if not, where there is a shortage, how can that deficiency be removed?

   

Celebrate your Little Achievements:

   

You can celebrate your small successes, such as giving a treat or a small party to yourself or family or to a best friend. By doing all this, you thicken yourself to achieve more and other people also thicken you.

 

Read more such articles here: https://poemluv.com/

 

Read more such articles

How to Set Goal of Life-[No Goals No Success! Must Read]

 

Know How you can Achieve Anything with Power of Belief !!

 

[How to Be Successful ] – [3 Amazing LAWS OF SUCCESS]

 

3 Tips to be Successful in Life -[Your Attitude is Everything ]

 

How to Achieve Goals-[Has Giving up Become Your Habit?]

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。

多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。

 

 

NTPサーバとの疎通確認

何はともあれ、まずはNTP側との疎通と動作確認が必要です。

以下のコマンドを実行してください。

※ESXiにはntpdateコマンドはないのでスキップしてください。

/sbin/ntpdate -b -u <ntp server ip>

/sbin/ntpdate -d <ntp server ip>

上のコマンドはNTPサーバと同期するコマンドです。NTPデーモンは時間がずれすぎている同期してくれないので、まずはこのコマンドで強制的に時間を合わせます。

下のコマンドはntpサーバの正常動作を確認するコマンドです。

このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。

 

NTPサーバとの同期に時間がかかっている可能性

NTPサーバとの同期は一時間くらいかかることもあります。

その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。

/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。

以下のような感じです。

##

    48  server <ntp server ip> iburst

    49  trustedkey

##

上記の設定があることで何十分も同期を待たずに済みます。

実施後は/etc/init.d/ntpd restart でサービスを再起動してください。

なお、NTPサーバとしてインターネット上の公開NTPサーバを指定している場合はiburstは利用しないか、利用可能かどうかをサーバの管理者にお尋ねください。

社内のNTPサーバの場合はほぼほぼ問題ないとは思いますが、確認しておいた方が無難です。

 

NTPサーバからの時刻が信頼されていない可能性

iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。

VCSAの場合

# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'

remote <ntp ip address>, local <ntp ip address>

hmode client, pmode unspec, stratum 2, precision -6

leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737

ppoll 6, hpoll 6, keyid 0, version 4, association 57089

reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0

timer 0s, flags config, bclient

reference time:      dc0bbd00.3f21a2e7  Tue, Dec 27 2016  1:00:00.246

originate timestamp: dc0c6b35.c3fed202  Tue, Dec 27 2016 13:23:17.765

receive timestamp:   dc0c6b35.c3d4dc75  Tue, Dec 27 2016 13:23:17.764

transmit timestamp:  dc0c6b35.c3bfd0d1  Tue, Dec 27 2016 13:23:17.764

filter delay:  0.00032  0.00032  0.00000  0.00000

               0.00000  0.00000  0.00000  0.00000

filter offset: 0.000801 0.000480 0.000000 0.000000

               0.000000 0.000000 0.000000 0.000000

filter order:  0        1        2        3

               4        5        6        7

offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791

 

ESXiの場合

# /usr/sbin/ntpq -classoc

ind assid status  conf reach auth condition  last_event cnt

===========================================================

  1 63674  961a   yes   yes  none  sys.peer    sys_peer  1

 

# /usr/sbin/ntpq -c "rv 63674"    <<<< rv xxxx のIDは↑のコマンドのassidで確認

associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,

srcadr=ntp-sv1.cpsd.local, srcport=123, dstadr=xxx.xxx.xxx.xxx, dstport=123,

leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,

refid=10.30.48.37,

reftime=e2b64f76.e5a956e2  Mon, Jul 13 2020  3:11:50.897,

rec=e2b650cc.9a6cec7e  Mon, Jul 13 2020  3:17:32.603, reach=377,

unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,

keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,

xleave=0.039,

filtdelay=     0.74    0.70    0.74    0.68    0.69    0.73    0.76    0.79,

filtoffset=    3.37    3.21    2.94    2.99    2.91    2.83    2.40    1.89,

filtdisp=      0.00   16.02   32.31   48.08   64.13   79.52   95.43  111.65

 

 

このコマンド出力中で注目すべきところは太字で強調したflash のところです。

flashの値は簡単にいえばエラーコードみたいなものです。

上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。

flashの値の意味についてはntpのソースコードのヘッダファイルに説明があります。

 

 

#### ヘッダファイル引用
+++++ include/ntp.h
/*                                                                                                                    
* Define flasher bits (tests 1 through 11 in packet procedure)                                                       
* These reveal the state at the last grumble from the peer and are                                                   
* most handy for diagnosing problems, even if not strictly a state                                                   
* variable in the spec. These are recorded in the peer structure.                                                    
*                                                                                                                    
* Packet errors                                                                                                      
*/
#define TEST1           0X0001  /* duplicate packet */
#define TEST2           0x0002  /* bogus packet */
#define TEST3           0x0004  /* protocol unsynchronized */
#define TEST4           0x0008  /* access denied */
#define TEST5           0x0010  /* authentication error */
#define TEST6           0x0020  /* bad synch or stratum */
#define TEST7           0x0040  /* bad header data */
#define TEST8           0x0080  /* autokey error */
#define TEST9           0x0100  /* crypto error */
#define PKT_TEST_MASK   (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
                        TEST6 | TEST7 | TEST8 | TEST9)
/*                                                                                                                    
* Peer errors                                                                                                        
*/
#define TEST10          0x0200  /* peer bad synch or stratum */
#define TEST11          0x0400  /* peer distance exceeded */
#define TEST12          0x0800  /* peer synchronization loop */
#define TEST13          0x1000  /* peer unreacable */

#define PEER_TEST_MASK  (TEST10 | TEST11 | TEST12 | TEST13)
####

 

上記のように定められています。
今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。
(多くの場合はこれが原因と思います・・・)
これは要するに同期先のNTPサーバまでの距離が遠いということです。
(距離が遠いと信頼性が下がりますからね。違ったら御免なさい)

 

 

デフォルトで許容されるホップ数がいくつなのかは不明ですが、
とりあえず増やしてあげれば解決する理屈です。
なのでホップ数を30まで増やすためにtosコマンドを/etc/ntp.confに追記しましょう。
まとめるとこんな感じです。

 

 

## /etc/ntp.conf

    48  server <ntp ip address > iburst  <<<< iburst 追記
    49  trustedkey
    50
    51  tos maxdist 30        <<<< 追記


##

 

この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。

0x400以外の問題については別の対応が必要になると思います。

また、flash codeが正常 (0x00)なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。

 

(補足)NTPサーバがWindwos OSの場合

WindowsサーバをNTPサーバとして構築している場合、デフォルトの設定では同期可能なNTPサーバとしてみなされない場合があります。

おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。

 

 

関連ドキュメント

Dell EMC KB

VxRail: How to troubleshoot NTP issue in VxRail cluster | Dell US

 

NTPDのパラメタ

Miscellaneous Commands and Options

For updates on this blog and other blogs: Follow @SteveIDM

 

When troubleshooting SAML/OIDC, its extremely useful to have access to your HTTP headers to validate what is being passed from one provider to the next.  This is very straight forward on Windows and MacOS devices but not quite as easy when we need the headers on a mobile device.

 

There are many tools on the market that can help proxy your mobile traffic. Most people default to Fiddler however I've personally had very little luck with fiddler for this purpose as Fiddler tends to truncate the SAML request thus making it useless for debugging SAML Traffic.  I credit a former colleague of mine, Eugene for introducing me to a tool called MITM Proxy. As the name suggests, its a man in the middle product but useful in troubleshooting.

Please note - This is not an endorsement of this specific tool, its just a tool that I've had success with.  The usual disclaimer with any third party product, please use at your own risk.

 

Before you start, make sure your Corporate IT department won't block this tool as its quite common. You might see something like this:

Screen Shot 10-15-20 at 09.27 AM.PNG

Getting Started with MITM Proxy

  1. Download MITM Proxy from https://mitmproxy.org/
  2. Install MITM Proxy as per their instructions. https://docs.mitmproxy.org/stable/overview-installation/
    Note: Install this proxy on a system that is accessible by your mobile device.
  3. Since running MITM Proxy on Windows 10, I will launch the MITM Proxy UI from the start menu.
    Screen Shot 10-15-20 at 10.36 AM.PNG
  4. If everything goes well, you will see a CMD window displaying the proxy was successfully started and a browser tab open display the debug window.
  5. In my case, it doesn't go well and I get the following error:
    Screen Shot 10-15-20 at 10.40 AM.PNG
    1. This error does not necessarily mean your Corporate IT team is blocking the application (Although I've thought this many times). It most likely means you have a port conflict. Run a netstat and verify that 8080 and 8081 are not being used.
    2. If 8080 is taken, you will need to start this manually in a command window using a free port
      C:\Program Files (x86)\mitmproxy\bin>mitmweb.exe --listen-port 8888
    3. If 8081 is taken, you will need to start this manually in a command window using a free port
      C:\Program Files (x86)\mitmproxy\bin>mitmweb.exe --web-port 8082
      There is a way to make these changes permanent using YAML but I've not figured that out yet.

  6. Hopefully, you now have the application started and you see the console open in a web browser.
    Screen Shot 10-15-20 at 10.49 AM.PNG

    Please Refer to MITM Proxy Troubleshooting for help with any other error to start this application.



Setting up your IOS Device

  1. On your IOS Device, go to your Settings Application
  2. Click on WiFi
  3. Click the "i" beside your WiFi network
    Screen Shot 10-15-20 at 10.58 AM 001.PNG
  4. Click on Configure Proxy at the bottom of the screen
    Screen Shot 10-15-20 at 10.58 AM.PNG
  5. Select Manual
  6. Enter the correct IP Address and Port
    Screen Shot 10-15-20 at 11.00 AM.PNG
  7. Open Safari and verify that you can see traffic in the console by going to any http url ie. http://www.google.com (Ignore the connection is not private error).

 

Installing SSL Certificate for HTTPS Decryption

 

  1. Open Safari on your mobile device, and go to http://mitm.it
    Screen Shot 10-15-20 at 11.26 AM.PNG
  2. Click on the Apple Link to download your profile.
  3. Go to your IOS Profiles and install the downloaded profile.
    Screen Shot 10-15-20 at 11.29 AM.PNG
  4. In the Settings Application, Click on General -> About
    Screen Shot 10-15-20 at 11.32 AM.PNG
  5. Scroll down and click on "Certificate Trust Settings"
  6. Enable Full Trust for the MITM Proxy Certificate
    Screen Shot 10-15-20 at 11.33 AM 001.PNG
  7. You should now see full headers in your web console.
  8. You can use any online SAML Decoder to get full access to the SAML Requests/Responses
    Screen Shot 10-15-20 at 11.36 AM.PNG

 

How to support Certificate Based Authentication

If you need to perform certificate based authentication, you can not 'intercept' a certificate challenge from the Workspace ONE CAS server. You will need to bypass the Cert Challenge from proxying through MITM

  1. Although you can modify settings on the fly using the UI, its probably easier to add the following switch when starting your MITM Proxy Server:
    mitmweb.exe --web-port 8082 --ignore-hosts "^(cas|cas-aws).*"

Screen Shot 10-15-20 at 12.38 PM.PNG

vSphere 7.0 U1  では「vSphere with Kubernetes」が「vSphere with Tanzu」になり、

製品構成や技術的な面で vSphere 環境で Tanzu Kubernetes Grid による Kubernetes が利用しやすくなりました。

たとえば、NSX-T がなくても Kubernetes が利用できるようになりました。

 

その一方で、vSphere 7.0 のときと同様の、NSX-T を組み込んだスーパーバイザー クラスタも利用できます。

ただ、スーパーバイザー クラスタを作成する「ワークロード管理」の有効化にも

少し手順変更があったので、主な差分について紹介しておきます。

 

ドキュメントでは下記のあたりです。

(若干 vSphere 7.0 からの差分は確認しにくいかなと思います)

ワークロード管理の有効化

 

なお、おおまかな流れとしては以前に投稿したスーパーバイザー クラスタのラボ構築手順で、

vSphere 7.0 U1 でも環境構築できるはずです。

vSphere with Kubernetes ラボ環境構築。(まとめ)

 

「ワークロード管理」有効化の準備。

vSphere や、NSX-T の準備については、vSphere 7.0 時点とほぼ同様です。

ただし、Tanzu Kubernetes Grid(TKG)のコンテンツ ライブラリを、事前に作成しておくようになりました。

 

vSphere 7.0 時点では、TKG の OVF テンプレートををダウンロードする

コンテンツ ライブラリを、Tanzu Kubernetes Cluster を作成する前に作成する必要がありました。

7.0 U1 では「ワークロード管理」を有効化する前に、コンテンツ ライブラリの準備が必要になります。

コンテンツ ライブラリ未作成の場合は、エラーとなり「ワークロード管理」有効化を開始できません。

wcp-70u1-01.png

 

そこで、事前準備として TKG のコンテンツ ライブラリを作成しておきます。

これは下記投稿での「コンテンツ ライブラリの準備」にある手順と同様です。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

 

ライブラリに含まれる OVF(Kubernetes のバージョン)は増えており、

この投稿の時点では下記のようになっています。

wcp-70u1-08.png

 

「ワークロード管理」の有効化。

「ワークロード管理」の有効化は、ひと通り画面遷移を掲載しておきます。

 

以前の vSphere 7.0 時点での様子は下記をどうぞ。

vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

 

vSphere Client で「メニュー」→「ワークロード管理」を開くと、

まず、ライセンス追加、もしくは評価版利用者の基本情報入力する画面が追加されています。

wcp-70u1-10.png

 

評価版として利用する場合は、情報を入力して「開始する」をクリックすると、下記画面に遷移します。

「開始する」で次に進みます。

wcp-70u1-12.png

 

「vCenter Server とネットワーク」画面の「ネットワーク スタック オプションを選択します」にて、

「NSX-T」もしくは「vCenter Server Network」を選択します。

今回は、従来どおり「NSX-T」を選択します。

wcp-70u1-13.png

 

「クラスタを選択」の画面は、7.0 と同様に、対象のクラスタを選択します。

wcp-70u1-16.png

 

ここからは、以前の vSphere 7.0 の頃と同様の情報入力が続きます。

「制御プレーンのサイズ」を選択します。

wcp-70u1-17.png

 

「ストレージ」で、用途ごとに仮想マシン ストレージ ポリシーを選択します。

wcp-70u1-18.png

 

「管理ネットワーク」の情報を入力します。

vSphere 7.0 U1 では、管理とワークロードとで入力画面が明確に分割されました。

wcp-70u1-20.png

 

「ワークロード ネットワーク」の情報を入力します。

wcp-70u1-21.png

 

「TKG 構成」は、vSphere 7.0 U1 から追加されました。

事前に作成した、TKG のコンテンツ ライブラリを選択します。

ただし、TKG と同時に Tanzu Kubernetes Cluster が作成されるわけではありません。

wcp-70u1-24.png

 

「確認」で、「完了」をクリックすると、処理が開始されます。

wcp-70u1-25.png

 

しばらく(ラボ環境では数十分)待つと、「ワークロード管理」が有効化されます。

これで、スーパーバイザー名前空間が作成できるようになります。

ちなみにクラスタ名の隣にある「!」マークが表示されているのは、評価版のためです。

wcp-70u1-27.png

 

Tanzu Kubernetes Cluster の変更点。

Tanzu Kubernetes Cluster(TKC)の作成方法は、vSphere 7.0 と同様です。

(下記投稿からの流れのように作成できます)

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

 

ただし、デフォルトの CNI が Calico から Antrea になりました。

TKC を定義するマニュフェスト(YAML 形式)で CNI を定義していない場合は、Antrea がインストールされます。

 

例えば、下記のような YAML で TKC を作成してみます。

 

tkg-cluster-03.yml · GitHub

---

kind: TanzuKubernetesCluster

apiVersion: run.tanzu.vmware.com/v1alpha1

metadata:

  name: tkg-cluster-03

spec:

  distribution:

    version: v1.18.5

  topology:

    controlPlane:

      count: 1

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

    workers:

      count: 1

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

  settings:

    network:

      services:

        cidrBlocks: ["10.16.0.0/12"]

      pods:

        cidrBlocks: ["10.32.0.0/12"]

 

この YAML では、あえて CNI の指定(下記のような)は省略しています。

・・・

spec:

  settings:

    network:

      cni:

        name: antrea #or calico

・・・

 

TKC を作成します。

$ kubectl apply -f ./tkg-cluster-03.yml

 

kubectl vsphere login でログインした後に、作成された TKC を確認すると、

Antrea が利用されていることがわかります。

wcp-70u1-tkc-01.png

 

以上、vSphere 7.0 U1 での「ワークロード管理」有効化の様子でした。

For updates on this blog and other blogs: Follow @SteveIDM

 

There are many use cases when integrating ADFS with Workspace ONE. In this blog, I'm going to focus on the use case of using Workspace ONE as a claims provider.  The VMware documentation for integrating ADFS and Workspace ONE is quite good. Please reference the VMware Documentation for the official steps on this integration.  My blog is intended to compliment the official  documentation.

 

In this blog, we will focus on:

 

Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.

Creating Workspace ONE Access as a Claims Provider

Download Workspace ONE Access Metadata

  1. Log into your Workspace ONE Access Administration Console.
  2. Go to Catalog -> Web Apps
  3. Click on Settings
  4. Click on SAML Metadata
    Screen Shot 10-08-20 at 04.06 PM.PNG
  5. Right-Click and Download your Identity Provider (IdP) Metadata.

 

Create your Claims Provider Trust


Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.

  1. Launch your ADFS Management Console
  2. Right Click on Claims Provider Trust and click "Add Claims Provider Trust"
    Screen Shot 10-08-20 at 11.25 AM.PNG
  3. Click Start
  4. Select " Import data about the claims provider from a file"
  5. Select the Workspace ONE Metadata file you just downloaded.
  6. Click Next
  7. Select a Display Name that is recognizable to your users. This name will appear on the ADFS Home Realm Discovery Page.
  8. Click Next
  9. Click Next
  10. Click Close

 

Configure Claim Rules

  1. Right Mouse on the newly created Claims Provider Trust and Click Edit Claims Rules
  2. Click Add Rule
  3. Select "Send Claims Using a Custom Rule" and Click Next
  4. Provide a Rule Name
  5. Paste the following Custom Rule. This rule will transform the incoming claim (Windows Account) and set AD as the source. In using this custom rule, we will not need to modify any existing Relying Parties that are already configured.

    c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",

    Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] ==

    "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"]

    => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",

    Issuer = "AD AUTHORITY", OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);


    Screen Shot 10-08-20 at 11.47 AM.PNG

  6. Click Finish
  7. Click OK

 

Configuring the ADFS Application Source in Workspace ONE Access

  1. Download the federation metadata file for the AD FS server by navigating to the URL: https://{ADFSdomain}/FederationMetadata/2007-06/FederationMetadata.xml where {ADFSdomain} is replaced with the fully qualified domain name (FQDN) your AD FS server.
  2. Log into the Workspace ONE Access Admin Console
  3. Select Catalog -> Web Apps
  4. Click the Settings button
  5. Click Application Sources
  6. Click the ADFS Application Source
    Screen Shot 10-08-20 at 03.47 PM.PNG
  7. Click Next
  8. Past the contents of the previously downloaded ADFS Metadata into the URL/XML box. It is recommended you paste the contents rather than pasting the URL.
    Screen Shot 10-08-20 at 03.49 PM.PNG
  9. Click Next
  10. Click Next
  11. Click Save
  12. Click the ADFS Application Source again.
  13. Click the configuration tab
  14. Change the Username Format to Unspecified
  15. Change the Username Value to "${user.domain}\${user.userName}"
    Screen Shot 10-08-20 at 03.53 PM.PNG
  16. Expand Advanced Properties
  17. Set Include Assertion Signature to Yes.
  18. For Signature Algorithm, select SHA256 with RSA.
  19. Change the Digest Algorithm to SHA256
    Screen Shot 10-08-20 at 03.55 PM.PNG
  20. Click Next and Save

 

Testing the Workspace ONE Claims Provider

  1. Open a Private Browser
  2. Navigate to Service Provider that is using ADFS
    Screen Shot 10-08-20 at 04.09 PM.PNG
  3. Verify that you see the ADFS Home Realm Discovery Page. Note: Your page will look different depending on how many claims providers you have configured.
    Screen Shot 10-08-20 at 04.10 PM.PNG
  4. Select the option for Workspace ONE
  5. Enter your Credentials for Workspace ONE
  6. Verify that Workspace ONE responds with a successful SAML Response. Using a SAML Tracer, you can verify that the NameID is returned in a Domain\username format
    Screen Shot 10-08-20 at 04.14 PM.PNG

Configure Workspace ONE Access as the default Claims Provider for an RP

If you have specific applications where you want to redirect all traffic for that application to Workspace ONE, you can perform the following steps:

  1. On the AD FS server, open a PowerShell session with elevated administrator rights.
  2. Run the following Powershell command

    Set-ADFSRelyingPartyTrust -TargetName "{RP_app}" -ClaimsProviderName "{VMWARE IDENTITY MANAGER CLAIMS PROVIDER}"

    Replace the placeholders in the command as follows.
    Replace {RP_app} with the name of the relying party trust corresponding to the target application.
    Replace {VMWARE IDENTITY MANAGER CLAIMS PROVIDER} with the name of the claims provider trust that you configured for VMware Workspace ONE Access.
    Use the names of the relying party trust and claims provider trust as they appear in the AD FS Management console.

 

 

Modifying your Onload.js

Depending on your use case, you may or may not want to do redirect all applications or all platforms for a particular application to Workspace ONE Access. As we saw above, the ADFS Home Realm Discovery page will by default prompt the user to select the claims provider.  Assuming you will not run the previous PowerShell command to default traffic for particular relying party to Workspace ONE Access, we will need to use the onload.js to automate the selection for the users.

 

We will walk through some of your options in the onload.js. First, lets address some things that you can NOT do:

  • You can not redirect to Workspace ONE Access based on username. Although it may appear that usernames appear in the request, you can not code for this reliably. If you use auto acceleration in Azure AD, you will not get usernames in the request.
  • You can not redirect based on groups.
  • You can not redirect based on network range.
  • You can not redirect based on having an enrolled device in Workspace ONE UEM.

 

Before we walk through what we can do, lets get started by exporting the current ADFS WebTheme.

 

  1. Log into the ADFS Server
  2. Run PowerShell as an Administrator
  3. Create a working folder by running the following command

    mkdir c:\myscripts

  4. Export the default ADFS web theme

    Export-AdfsWebTheme –Name "Default" –DirectoryPath c:\myscripts

  5. In PowerShell, create a new AD FS web theme

    New-AdfsWebTheme –Name "VIDM" –SourceName "Default"

  6. Re-import the onload.js into the new Web Theme

    Set-AdfsWebTheme -TargetName VIDM -AdditionalFileResource @{Uri='/adfs/portal/script/onload.js';path="c:\myscripts\script\onload.js"}

  7. Activate the new web theme

    Set-AdfsWebConfig -ActiveThemeName "VIDM"

  8. To save your changes, you will need to restart the AD FS instance

    Restart-Service adfssrv

  9. Open C:\myscripts\script\onload.js in a text editor such as Notepad++
  10. In the next couple section we will go through the possible options that you can make in the onload.js.  Once you make a change, you will need to re-import the onload.js. You do not need to activate or restart ADFS.
    We are going to use the following placeholders in the following sections:
    {AccessTenant} = FQDN of the VMware Workspace ONE Access service ie. https://dsas.vmwareidentity.com
    {AD FS Claims Provider} = 'AD Authority'  Note: For older ADFS environments, you might need to use: 'http://{ADFSdomain}/adfs/services/trust'

 

 

Redirecting Mobile Traffic

 

 

// redirect mobile traffic to Workspace ONE

if (navigator.userAgent.match(/iPad|iPhone|Android|Windows Phone/i) != null)

{

HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');

}else

{

HRD.selection(‘AD AUTHORITY’);

}

 

Support for IpadOS Devices

 

 

// ADDITIONAL LOGIC FOR iPadOS AND iOS 13 iPad DEVICES

if (navigator.userAgent.match(/Macintosh/i) != null)

{

if(navigator.maxTouchPoints > 2)

{

HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');

}

else

{

HRD.selection(‘AD AUTHORITY’);

}

}

 

Hiding the HRD Selection

// hide HRD selector from user

var hrdui = document.getElementById("bySelection");

hrdui.style.display = "none";

 

Applying Conditions to Only Specific Relying PartiesVM

You will need to do some testing to make sure you get the correct values. If you *TEMPORARILLY* add the following code it will help get the correct values:

document.write("\n<b>WindowsLocation=</b>");

document.write(window.location.href);

document.write("<br>\n\n<b>UserAgent=</b>");

document.write(navigator.userAgent);

document.write("<br>\n\n<b>DocumentReferer=</b>");

document.write(document.referrer);

 

 

There are two options to choose from:

Option 1:

if ( window.location.href.indexOf(“urn%3afederation%3aMicrosoftOnline”|“https%3a%2f%2flogin.microsoftonline.com%2fextSTS.srf”) != -1 )

{

HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');

}

Option 2:

if (document.referrer.indexOf("https://tenant.my.salesforce.com/") != -1){

HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');

}

 

 

Using ADFS Access Control Policies

If you are you using ADFS Access Control Policies, you might see some errors in the event viewer similar to:

 

"The caller is not authorized to request a token for the relying party "

"Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity  for relying party trust "

 

In order to comply with your Access Control Policies, we will need to add a policy to allow requests coming from Workspace ONE.

 

Here are two approaches that you can use:

 

Check for 'Federated Authority' in the Claims Request

This approach will not necessarily ensure the claim came from Workspace ONE. It will check if it came from a federated claim provider.

  1. Edit your Access Policy in ADFS
  2. Create a new rule that will permit users for a specific claim in the request.
  3. Select "Account Store" as the the Claim type and "FEDERATED AUTHORITY" as the Claim Value
    Screen Shot 10-09-20 at 09.37 AM 001.PNG
  4. Your Rule would look similar to this:
    Screen Shot 10-09-20 at 09.37 AM.PNG

Check for Specific Claim sent by Workspace ONE Access

In this approach, ADFS will validate a specific claim sent by Workspace ONE Access. There are a few more steps required in this approach.

  1. In Workspace ONE Access, open the Application Source for ADFS (Identity & Access Management -> Catalog -> Web Apps -> Settings)
  2. Click on Configuration and Expand Advanced Configuration
  3. Scroll down to Custom Attribute Mapping
  4. Add the attribute "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
  5. Select the format "Unspecified"
  6. Set the value to something like "WS1"
    Screen Shot 10-09-20 at 09.39 AM.PNG
  7. Click Next, Next, Save
  8. In ADFS, edit the Claim Rules for the Workspace ONE Claims Provider Trust
  9. Add A New Claim Rule
  10. Select "Pass Through or Filter an Incoming Claim"
  11. Provide a Name and Select "Role" as the incoming claim.
    Screen Shot 10-09-20 at 09.43 AM.PNG
  12. Click Finish. You may receive a warning, You can click OK or filter the claim value even further.
  13. Edit your Access Policy in ADFS
  14. Create a new rule that will permit users for a specific claim in the request.
  15. Select "Role" as the the Claim and "WS1" as the Claim Value
    Screen Shot 10-09-20 at 09.39 AM 001.PNG
  16. Your Rule would look similar to:
    Screen Shot 10-09-20 at 09.40 AM.PNG

 

 

NSX-T の分散ファイアウォール(DFW)を、VLAN セグメントで使用してみます。

前回は、簡単な動作確認をしてみました。

NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

 

今回は、vNIC のポートグループを「VLAN セグメント」と「分散ポートグループ」に

それぞれ切りかえて、DFW ルール適用の様子を確認してみます。

 

今回の DFW ルール。

NSX Manager の「分散ファイアウォール」の画面を確認すると、

ID 3048 の DFW ルールが作成されて、有効になっています。

 

このルールは、適用先が「分散ファイアウォール (DFW)」となっており、

基本的には NSX 環境内のすべての VM、つまりホスト トランスポート ノード上で

NSX によるセグメントに接続されているすべて VM に適用されます。

(例外もありますが、今回は省略)

 

ちなみに、今回は DFW ルールの適用される様子を見るだけなので、

通信は遮断しない(アクション: 許可)ルールにしてあります。

nsxt-dfw-vnic-02.png

 

「VLAN セグメント」接続の vNIC と DFW ルール。

VM「vm01」の vNIC が、NSX-T による VLAN セグメント「seg-vlan-0006」に接続されています。

この VLAN セグメントは前回の投稿で作成したもので、VLAN ID 6 が設定されています。

nsxt-dfw-vnic-03.png

 

それでは、vm01 が起動されている ESXi ホストに SSH 接続して、

vNIC への DFW ルール適用の様子を確認します。

まず に、DFW のルールが作成されている vNIC を確認しておきます。

 

ESXi に SSH ログインした状態です。

[root@lab-nsx-esxi-21:~] vmware -vl

VMware ESXi 7.0.0 build-16324942

VMware ESXi 7.0 GA

 

vm01 が起動しています。

この VM の World ID(371855)を記録しておきます。

[root@lab-nsx-esxi-21:~] esxcli network vm list

World ID  Name  Num Ports  Networks

--------  ----  ---------  --------

  371855  vm01          1

 

summarize-dvfilter で、vm01 の vNIC に適用されている dvfilter を探します。

赤字の部分が、vm01 の vNIC にあたります。

[root@lab-nsx-esxi-21:~] summarize-dvfilter

Fastpaths:

agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath

agent: vmware-si, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874

agent: vmware-sfw, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874

agent: nsx_bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vdrb-15945874

agent: ESXi-Firewall, refCount: 3, rev: 0x1010000, apiRev: 0x1010000, module: esxfw

agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter

 

ServiceVMs:

serviceVM: 1, agent vmware-sfw, refCount: 2, rev: 0x4, apiRev: 0x4, capabilities: csum,tso

serviceVM: 2, agent vmware-sfw, refCount: 1, rev: 0x4, apiRev: 0x4, capabilities: csum,tso

 

Filters:

world 0 <no world>

port 67108877 vmk0

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   serviceVMID: none

   filter source: Invalid

   moduleName: esxfw

port 67108878 vmk1

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   serviceVMID: none

   filter source: Invalid

   moduleName: esxfw

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

port 67108883 vm01.eth0

  vNic slot 2

   name: nic-371855-eth0-vmware-sfw.2

   agentName: vmware-sfw

   state: IOChain Attached

   vmState: Attached

   failurePolicy: failClosed

   serviceVMID: 1

   filter source: Dynamic Filter Creation

   moduleName: nsxt-vsip-15945874

 

さきほど確認した、VM の World ID をもとにすると、

vm01 のフィルタの名前を見つけやすいかなと思います。

vm01 の 1つめの vNIC(ゲスト OS の種類に関係なく eth0)のフィルタ名

「nic-371855-eth0-vmware-sfw.2」を見つけました。

[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

   name: nic-371855-eth0-vmware-sfw.2

 

そしてフィルタ名を指定して「vsipioctl getrules」コマンドを実行すると、

DFW のルールが実際に設定されている様子がわかります。

 

さきほど NSX Manager でも確認できた、ID 3048 のルールが表示されており、

vm01 の vNIC に DFW ルールが適用されていることがわかります。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2

ruleset mainrs {

  # generation number: 0

  # realization time : 2020-10-07T17:00:19

  # FILTER rules

  rule 3048 at 1 inout protocol any from any to any accept;

  rule 2 at 2 inout protocol any from any to any accept;

}

 

ruleset mainrs_L2 {

  # generation number: 0

  # realization time : 2020-10-07T17:00:19

  # FILTER rules

  rule 1 at 1 inout ethertype any stateless from any to any accept;

}

 

ちなみに、DFW が適用されていることは nsxcli コマンドでも確認できます。

この ESXi で起動されている VM(の vNIC)が 1つだけなので、Firewall VIF が 1件表示されています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"

                            Firewall VIFs

----------------------------------------------------------------------

 

VIF count: 1

1   1db50096-f1b8-44a2-8639-8ed6ac641446

 

 

「vDS の分散ポートグループ」接続の vNIC と DFW ルール。

続いて、NSX-T の VLAN セグメントと同じ VLAN ID の分散ポートグループを適用して、

DFW ルールの変化を確認してみます。(結果として DFW ルールは消えます)

 

vDS「vds-21」に作成されている、分散ポートグループの一覧です。

今回は NSX で利用している vDS に、VLAN セグメントと同様に、

VLAN ID 6 の分散ポートグループ「dvpg-vlan-0006」を作成しました。

nsxt-dfw-vnic-04.png

 

vm01 の vNIC のポートグループを、分散ポートグループである「dvpg-vlan-0006」に変更します。

nsxt-dfw-vnic-06.png

 

分散ポートグループに変更されました。

nsxt-dfw-vnic-07.png

 

このポートグループ変更より、DFW ルールが即時変更されます。

ESXi で summarize-dvfilter を実行してみると、

vm01 の「nic-371855-eth0-vmware-sfw.2」フィルタは存在したままです。

[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

   name: nic-371855-eth0-vmware-sfw.2

 

しかし、vsipioctl getrules コマンドで確認すると、DFW ルールが消えて「No rules」になりました。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2

No rules.

 

nsxcli コマンドでも 1件表示されていた VIF がなくなり、

Firewall VIF のカウントがゼロになっています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"

                            Firewall VIFs

----------------------------------------------------------------------

 

VIF count: 0

 

 

このように、VM が起動する ESXi が NSX-T のホスト トランスポート ノードとして設定されていたとしても、

vSS の標準ポートグループや vDS の分散ポートグループに接続された vNIC には、DFW ルールが適用されません。

DFW はオーバーレイ ネットワークでなくても使用できますが、

VLAN ネットワークで使用する場合、vNIC には「VLAN セグメント」を割り当てる必要があります。

 

以上、DFW を VLAN セグメントで使用してみる話でした。

NSX-T の分散ファイアウォール(DFW)は、NSX-T のセグメント(オーバーレイ or VLAN)で機能します。

今回は、VLAN セグメントでも DFW が利用できることを確認してみます。

 

ラボ環境について。

今回のラボ環境は、下記のように用意してあります。

NSX-T 3.0 のシンプルな DFW ラボを構築する。

特にオーバーレイ ネットワークやルーティング機能などは準備せず、

ただ「VLAN セグメント」が利用できるようになっています。

 

NSX-T では、VLAN セグメント「seg-vlan-0006」を作成してあります。

まず、NSX Manager の画面から確認しておきます。

セグメントはオーバーレイではなく、VLAN のトランスポート ゾーンに作成し、VLAN ID 6 を設定しています。

つまりこれは NSX-T で作成されたセグメントですが、Geneve のオーバーレイではなく VLAN によるものです。

dfw-01-00.png

 

vCenter(の vSphere Client)で vDS「vds-21」を確認すると、

「seg-vlan-0006」が表示されており、NSX の「N」マークがついています。

 

ちなみに、dvpg-vlan-0006 という NSX-T に関係しない、VLAN ID 6 の分散ポートグループも別途作成してあります。

※この分散ポートグループは次の投稿で利用します。

dfw-01-01.png

 

VM「vm01」の vNIC に、ポートグループとして NSX-T による VLAN セグメントを割り当てました。

なお、この VM の IP アドレスは 10.0.6.91 です。あとで、このアドレス宛に疎通確認します。

dfw-01-03.png

 

ESXi ホスト「192.168.10.21」で仮想スイッチの構成を確認すると、1つの vDS だけが構成されてます。

この vDS は NSX と統合されており、「NSX 仮想スイッチ」となっていることがわかります。

分散ポートグループやセグメントは、トポロジの図では実際に使用されているものだけが表示されています。

dfw-01-02.png

 

DFW ポリシー / ルールの作成。

NSX Manager で、DFW のポリシーとルールを作成します。

今回は、デフォルトで作成されているポリシーはそのままで、あえてポリシーを追加作成します。

そして、ルールの適用有無が分かりやすいように、すべての通信を許可 / 遮断するためのルールを、1つだけ作成します。

 

「セキュリティ」→「分散ファイアウォール」→「カテゴリ固有のルール」→「アプリケーション」を開きます。

デフォルト作成されるポリシー「Default Layer3 Section 」には、すべての通信を「許可」するルールが設定されているので、

今回の動作確認には特に影響しません。

 

この画面で「ポリシーの追加」をクリックすると「新規ポリシー」が作成されるので、

名前を「test-policy-01」に変更します。

dfw-01-11.png

 

追加された「test-policy-01」ポリシーを選択して、「ルールを追加」をクリックします。

dfw-01-14.png

 

「新規ルール」が作成されるので、「test-rule-01」に変更します。

ルールの「適用先」はデフォルトで「分散ファイアウォール」全体となっており、

NSX-T の オーバーレイ / VLAN セグメントに接続された VM に適用されます。

また、ルールの「送信元」、「宛先」、「サービス」は、いずれも「任意」になっているので、すべての通信が対象になります。

ただし、アクションは「許可」なので、このままでは通信の遮断はされません。

 

そして「発行」をクリックしてポリシー / ルールを保存しておきます。

dfw-01-16.png

 

ルールが保存され、このルールの ID は 3048 が採番されました。

このあと、このルールの設定を変更して、DFW の動作確認をします。

dfw-01-22.png

 

DFW ルールの動作確認。

それでは NSX 外部のマシンから、VLAN セグメントに接続されている vm01 宛に ping で疎通確認をしつつ、

DFW で通信を遮断してみます。

 

作成した DFW ルール「test-rule-01」のアクションを「許可」→「却下」に変更します。

※これはドロップより却下の方がデモ的に見栄えがよいため・・・

dfw-01-28.png

 

「発行」をクリックすると、ルールが適用されます。

この時点で vm01 宛に通信できる外部のマシンから ping を実行しつつ、「発行」をクリックします。

dfw-01-23.png

 

DFW のルールが作用して、外部の端末から vm01(10.0.6.91)への ping が通らなくなりました。

dfw-01-26.png

 

DFW ルール「test-rule-01」のアクションを「却下」→「許可」に戻して、「発行」をクリックすると・・・

dfw-01-29.png

 

外部の端末から、vm01 への ping が通るようになりました。

dfw-01-30.png

 

このように、オーバーレイ セグメントではなく、VLAN セグメントでも、NSX-T の DFW は動作します。

まずは、DFW が動作することの確認でした。

 

次は、VM の vNIC に「NSX の VLAN セグメント」ではなく「vDS の分散ポートグループ」を割り当てた環境で、

分散ファイアウォール ルールが動作しない様子を確認してみます。

つづく!

NSX-T には、分散ファイアウォール(DFW)機能があります。

この DFW は、NSX-T の有名な機能であるオーバーレイ ネットワーク(Geneve による)の環境でなくても利用可能です。

そこで今回は、オーバーレイ ネットワークなしのシンプルな DFW ラボ環境を構築してみます。

 

今回の環境。

今回のラボは、下記のような構成です。

  • vCenter Server 7.0d / ESXi 7.0
  • NSX-T 3.0
  • NSX の仮想スイッチは、N-VDS ではなく vDS 7.0 を利用(NSX-T 3.0 ~新機能)
  • NSX Edge は無し。オーバーレイ ネットワークも無し。

 

vCenter / ESXi の仮想スイッチは、分散仮想スイッチ(vDS)のみを構成しています。

vDS のバージョンは 7.0 で作成してあり、アップリンクには ESXi の物理 NIC(vmnic0 と vmnic1)が割り当てられています。

nsx-dfw-lab-01.png

 

NSX Manager の仮想アプライアンス(VM)は、すでにデプロイしてあります。

OVA ファイルは「nsx-unified-appliance-3.0.0.0.0.15945876-le.ova」です。

nsx-dfw-lab-02.png

 

なお、NSX-T の設定作業をするためにはライセンスの適用は必須です。

デプロイ直後の NSX Manger の VM を起動して、

評価ライセンスを適用してある状態です。

 

NSX Manager での vCenter 登録。

NSX-T に「コンピュート マネージャ」として vCenter を登録します。

これは、NSX-T の仮想スイッチで vDS を利用するために必要です。

 

「システム」→「ファブリック」→「コンピュート マネージャ」を開き、

「追加」をクリックして「コンピュート マネージャの作成」画面を表示します。

そして、下記を入力して「追加」をクリックします。

  • vCenter の「名前」(これは任意の文字列)
  • vCenter の「FQDN または IP アドレス」
  • vCenter の、ユーザー名と、パスワード

nsx-dfw-lab-04.png

 

画面に従って証明書のサムプリントを受け入れると、vCenter がコンピュート マネージャとして登録されます。

nsx-dfw-lab-06.png

 

これで、「システム」→「ファブリック」→「ノード」→

「ホスト トランスポート ノード」で vCenter を選択すると、クラスタと ESXi が表示されるようになります。

nsx-dfw-lab-07.png

 

ただしこの ESXi は、まだ NSX-T むけに準備されていない状態です。

 

ESXi のホスト トランスポート ノードとしての準備。

ここから ESXi を、NSX-T の「ホスト トランスポート ノード」として準備します。

 

まず、「システム」→「ファブリック」→「プロファイル」→

「トランスポート ノード プロファイル」で、「追加」をクリックします。

 

「トランスポート ノード プロファイルの追加」画面が表示されるので、

下記を入力して、そのまま画面を下にスクロールします。

  • プロファイルにつける「名前」を入力。今回は tnp-esxi-vds-01 としています。
  • ノード スイッチの「タイプ」で、「VDS」を選択。
  • ノード スイッチ「名前」では、vCenter と vDS 名を選択。(例での vDS は vds-21)
  • トランスポート ゾーンとして「nsx-vlan-transportzone」を選択。
    (これは、デフォルト作成される VLAN トランスポート ゾーン)
  • アップリンク プロファイルとして「nsx-default-uplink-hostswitch-profile」を選択。

nsx-dfw-lab-09.png

 

画面下にスクロールして、下記を入力してから「追加」をクリックします。

  • uplink-1 → vDS の1つめのアップリンク名(例では dvUplink1)
  • uplink-2 → vDS の2つめのアップリンク名(例では dvUplink2)

nsx-dfw-lab-10.png

 

これで、VLAN セグメントを利用できるようになる、トランスポート ノード プロファイルが作成されました。

nsx-dfw-lab-11.png

 

「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、

クラスタ(ESXi ではなくその上の)を選択して、「NSX の設定」をクリックします。

「NSX のインストール」画面が表示されるので、先ほど作成したトランスポート ノード プロファイルを選択して、

「適用」をクリックします。

nsx-dfw-lab-14.png

 

これで少し待つと、クラスタ配下の ESXi が NSX のホスト トランスポート ノードとして設定された状態になります。

nsx-dfw-lab-16.png

 

NSX-T によるネットワークの準備。

このラボでは DFW だけを利用するため、NSX Edge はデプロイしていません。

そして、ルーティングのための Tier-0 / Tier-1 ゲートウェイや、Geneve のオーバーレイ セグメントも作成しません。

VLAN 接続するための「VLAN セグメント」のみ作成します。

 

Tier-0 ゲートウェイは、作成しません。

nsx-dfw-lab-17.png

 

そして Tier-1 ゲートウェイも作成しません。

nsx-dfw-lab-18.png

 

NSX-T では、vCenter でポートグループとして扱える「セグメント」を作成できます。

そして NSX-T の DFW は、この「セグメント」で作用します。

NSX-T のセグメントには、「オーバーレイ」と「VLAN」の 2種類がありますが、DFW はどちらでも利用できます。

そこで、ここでは「VLAN セグメント」のみを作成します。

 

「ネットワーク」→「セグメント」にある、「セグメント」タブで、「セグメントの追加」をクリックします。

そして下記を入力して、画面を下にスクロールします。

  • セグメント名を入力。ここでは seg-vlan-0006。
  • トランスポート ゾーンを選択。デフォルトで作成されている「nsx-vlan-transportzone | VLAN」を選択する。

nsx-dfw-lab-21.png

 

VLAN ID を入力し、「保存」をクリックします。

今回は、セグメント名からもわかるように VLAN ID 6 のセグメントを作成します。

ちなみに、この VLAN ID は(NSX 外部の)物理スイッチのトランク ポートでも設定しておく必要があります。

nsx-dfw-lab-23.png

 

このセグメントの設定を続行するかという確認メッセージは、「いいえ」で閉じます。

nsx-dfw-lab-24.png

 

これで、VLAN セグメントが作成されました。

ここで作成した、VLAN セグメント「seg-vlan-0006」は、

vCenter の vSphere Client などでは、ポートグループとして VM の vNIC に割り当てられます。

nsx-dfw-lab-26.png

 

これで、DFW を利用可能な、シンプルな構成のラボが構築できました。

つづく。

NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

For updates on this blog and other blogs: Follow @SteveIDM

 

Workspace ONE Access will soon offer a native integration with DUO. This integration will not require the use of radius and/or the Workspace ONE Access connector.

 

This blog will outline the steps to setup and configure DUO and Workspace ONE Access.

 

Please remember, this integration is not yet generally available.

 

1. Create a Web SDK Application in DUO

  1. In your DUO admin console, go to Dashboard -> Applications -> Protect an Application
    Screen Shot 10-06-20 at 03.08 PM.PNG
  2. In the search box, enter "Web SDK" and Click Protect
    Screen Shot 10-06-20 at 03.18 PM.PNG
  3. Make note of your Integration Key, Secret Key and API Hostname
    Screen Shot 10-06-20 at 03.20 PM.PNG
  4. Scroll down to settings and update the name of this application.
    Screen Shot 10-06-20 at 03.22 PM.PNG
  5. Click Save

 

2. Enable the Workspace ONE Authentication Method

  1. Log into the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Authentication Methods
    Screen Shot 10-06-20 at 03.26 PM.PNG
  3. Click Edit for "DUO Security"
    Screen Shot 10-06-20 at 03.29 PM.PNG
  4. Enable the Adapter
  5. Paste your Integration Key.
  6. Paste your Secret Key
  7. Paste your API Host Name
  8. Select the correct username format. The only options currently available are username and email address.
  9. Select Save
  10. Your DUO Adapter should be enabled and ready to use.

 

3. Update your "Built-In" IDP in Workspace ONE Access

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Identity Providers
  3. Click on your "Built-In" Identity Provider that is already associated with your user directory.
  4. Scroll down to Authentication Methods and enable DUO Security
    Screen Shot 10-06-20 at 03.42 PM.PNG
  5. Click Save

 

4. Update your Policies

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Policies
  3. Edit your Default or Application Policy (depending on your requirements)
  4. Add DUO Security as a second factor of authentication.
    Screen Shot 10-06-20 at 03.47 PM.PNG
  5. Click Save
  6. Click Next and Save

 

Testing the DUO Flow:

 

  1. Log into your Workspace ONE Access Console (via incognito)
  2. Enter your Username/Password (as an End User)
    Screen Shot 10-06-20 at 03.50 PM.PNG
  3. Click on Start Setup
    Screen Shot 10-06-20 at 03.50 PM 001.PNG
  4. Select your device type and click Continue
    Screen Shot 10-06-20 at 03.51 PM 001.PNG
  5. Select the correct platform for your device and click Continue
    Screen Shot 10-06-20 at 03.52 PM.PNG
  6. Workspace ONE Access will Prompt you to install Duo Mobile. Once you have DUO Mobile Installed, Click "I have DUO Mobile"
    Screen Shot 10-06-20 at 03.53 PM.PNG
  7. In DUO Mobile, click the + sign and scan the barcode
    Screen Shot 10-06-20 at 03.55 PM.PNG
  8. Once activated, you will see a green check mark.
    Screen Shot 10-06-20 at 03.56 PM.PNG
  9. Click Continue
  10. When prompted, select "Send Me a Push"
    Screen Shot 10-06-20 at 03.57 PM.PNG
  11. On your device, click Approve.
    Screen Shot 10-06-20 at 03.58 PM.PNG

For updates on this blog and other blogs: Follow @SteveIDM

 

I've had quite a few requests lately for assistance setting up SCIM capabilities with OneLogin and Workspace ONE.

 

In full disclosure, I've set this up in my lab but I've not done full end to end testing of all CRUD capabilities.

 

The one obvious difference in the setup and configuration with OneLogin over some of our other partners is the ability to support the Authorization Code Grant Flow.  Big Kudos to the OneLogin team.

 

Lets look at the high level steps:

  1. Create a directory instance in Workspace ONE Access
  2. Create a OneLogin Remote App Access Client.
  3. Configure VMware Workspace ONE application in OneLogin.

 

Create Directory Instance in Workspace ONE Access

In order to create a directory instance in Workspace ONE Access, we'll need to use the API because the type of directory required for this integration can not currently be done using the Admin Console. In the following steps we'll use Postman to run the necessary API calls.

  1. We will need an Oauth Token in order to use the API.  Please see my other blog on your options on getting an OAuth Token
  2. Open a new tab in Postman, Select POST and the method.
  3. For the URL, enter: https://[TENANTURL]SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
    https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  4. In the Authorization Tab, Select either BEARER Token or OAuth 2.0 depending on the option you chose in Step 1 to get a token. Select or Paste your Token.
  5. In the Headers Tab, Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
  6. Click on the Body Tab
  7. Use the following as a sample and Click Send:
    {
    "type":"OTHER_DIRECTORY",  
    "domains":["onelogin.com"],    
    "name":"OneLogin Directory" 
    }
  8. In the Workspace ONE Admin Console, verify that the directory is created and is associated with the correct domain.
    Screen Shot 09-25-20 at 03.03 PM.PNG

Create a OneLogin Remote App Access Client

We will now create a OneLogin Application in Workspace ONE Access which will be used by OneLogin to create/update/delete users in Workspace ONE.

  1. In the Workspace ONE Admin Console, go to Catalog -> Webapps
  2. Click New (Top Left)
  3. Enter a Name ie. OneLogin SCIM
    Screen Shot 09-25-20 at 03.09 PM.PNG
  4. Click Next
  5. On the configuration page, you will need to enter:
    SettingValue
    Authentication TypeOpen ID Connect
    Target URLEnter your OneLogin Tenant ie. https://tenant.onelogin.com
    Redirect URLhttps://admin.us.onelogin.com/provisioning/oauth_redirect_uri
    Client IDEnter a value for the Client ID: ie. OneLoginSCIM
    Client SecretEnter a value for the Client Secret ie. Test12345
    Show in User PortalNO
    Screen Shot 09-25-20 at 03.11 PM.PNG
  6. Click Next
  7. Click Next for Access Policy
  8. Click Save
  9. Assign the application to your System Domain user
    Screen Shot 09-30-20 at 09.51 AM.PNG

 

This wizard will create a new remote app access client that will be used by OneLogin. You can see the client which was created by going to Catalog -> Settings -> Remote App Access.

 

Warning: Do NOT edit the scopes. You will not be able to re-add the Admin scope if you do.

Screen Shot 09-25-20 at 03.20 PM.PNG

 

Configure VMware Workspace ONE application in OneLogin.

 

  1. In the OneLogin admin console, search for "VMware Workspace ONE" under Applications
    Screen Shot 09-25-20 at 03.24 PM.PNG
  2. Select and Click Save
  3. Click on Configuration on the left menu
  4. Under SCIM Base URL, enter: https://[tenant].vmwareidentity.com/SAAS/jersey/manager/api/scim
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim
  5. Under VMware Site, enter your tenant URL. This will be used as the Oauth Authorization Server URL.
    ie. https://dsas.vmwareidentity.com
  6. Under Client ID, enter the client ID you used in the previous step
  7. Under Client Secret, enter the secret you used in the previous step.
    Screen Shot 09-25-20 at 03.31 PM.PNG
  8. Click Save

    Please don't forget to hit SAVE!

  9. Go back to the Configuration Tab

    Before you Continue, you need to make sure your Policy in Workspace ONE Access will allow you to authenticate using System Domain credentials without using the backdoor.  You will need a policy similar to below. The Password (Local Directory) needs to be a fallback.
    Screen Shot 09-25-20 at 03.42 PM 001.PNG

  10. Under API Connection, Click Authenticate
    Screen Shot 09-25-20 at 03.32 PM.PNG
  11. In the pop up, click VMware Workspace ONE
    Screen Shot 09-25-20 at 03.33 PM.PNG
  12. When prompted to Authenticate, Select System Domain
    Screen Shot 09-25-20 at 03.39 PM.PNG
  13. Enter your Credentials
  14. You should be returned back to the One Login Portal with a Successful Authorization
    Screen Shot 09-25-20 at 03.40 PM.PNG
  15. Click on the Parameters Tab
  16. We will need to map the attributes appropriately that will be sent to Workspace ONE.

    In order to map the attributes correctly, we will need to understand how users are created in in OneLogin. Take a look at your users to ensure all the required attributes are set for all users that will be provisioned to Workspace ONE Access.  Attributes such as Username, External ID and User Principal Name are typically set if you have an external directory server. If you are creating users directly in OneLogin without a directory server you will need to select different attribute mappings.

  17. Map the attributes appropriately:
    VMware Workspace ONE FieldValue
    Distinguished NameDistinguished Name
    Email AddressEmail
    External IDIf ALL users are created in OneLogin from a directory server, select ExternalID
    If some users are created locally in OneLogin, select Internal ID.
    First NameFirst Name
    Last NameLast Name
    Name IDEmail
    SCIM Username

    If ALL users are created in OneLogin from a directory server, select Username

    If some users are created locally in OneLogin (without a username) , select Email

    User DomainEnter value used as the domain when creating the directory in Workspace ONE Access
    Screen Shot 09-25-20 at 03.59 PM.PNG
    User PrincipleName

    If ALL users are created in OneLogin from a directory server, select User Principal Name

     

     

    If some users are created locally in OneLogin, select Email

  18. Click Save
  19. Click Provisioning on the left menu, and enable the Provisioning Checkbox.
  20. Click Save
  21. Assign a user the application and verify it successfully provisions
    Screen Shot 09-25-20 at 04.12 PM.PNG

vSphere with Kubernetes のスーパーバイザー クラスタ上に作成した

「Tanzu Kubernetse Cluster」に、kubectl を使用していくつかの方法で接続してみます。

 

ドキュメントでは、下記のあたりが参考になります。

Tanzu Kubernetesクラスタ環境への接続

 

環境について。

今回の接続元の環境は Linux です。

スーパーバイザー クラスタの管理プレーンから、kubectl と vSphere プラグインはダウンロードしてあります。

$ cat /etc/system-release

Oracle Linux Server release 7.8

$ kubectl version --short --client

Client Version: v1.17.4-2+a00aae1e6a4a69

$ kubectl vsphere version

kubectl-vsphere: version 0.0.2, build 16232217, change 8039971

 

Tanzu Kubernetse Cluster のラボは、下記のように構築しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)

 

kubectl は、スーパーバイザー クラスタの制御プレーンからダウンロードしたものを利用しています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

 

vCenter Server 7.0b で、3ノードの ESXi で スーパーバイザー クラスタを構成しています。

スーパーバイザークラスタ「wcp-cluster-41」の、制御プレーンの IP アドレスは「192.168.70.97」です。

tkc-access-00.png

 

Tanzu Kubernetes Cluster(TKC)は、スーパーバイザークラスタの名前空間「lab-ns-03」に作成ずみです。

TKC の名前は「tkg-cluster-41」で、制御プレーンの IP アドレスは「192.168.70.99」です。

tkc-access-01.png

 

あらかじめ、vCenter Single Sign-On には、ID ソースとして LDAP サーバを登録ずみです。

tkc-access-02.png

 

ID ソースのドメイン「go-lab.jp」からユーザ情報を取得できています。

tkc-access-03.png

 

方法1: vCenter Single Sign-On 認証で接続する。

ここでは、「k8s-infra-user @ go-lab.jp」という vCenter Single Sigh-On のユーザーで接続してみます。

 

まず、対象のユーザーには、スーパーバイザー クラスタの名前空間で「権限の追加」が必要です。

そして、kubectl で TKC に接続する際は、スーパーバイザー制御プレーン宛となります。

ちなみに、vCenter の管理者ユーザ(administrator@vsphere.local)であれば、

デフォルトでスーパーバイザー クラスタや TKC にアクセス可能です。

tkc-access-case-01.PNG

 

1-1: スーパーバイザー名前空間での権限の追加。

スーパーバイザー クラスタの名前空間「lab-ns-03」の、

「サマリ」→「権限」にある「権限の追加」をクリックします。

tkc-access-04.png

 

ID ソース、ユーザー(またはグループ)、ロールを選択して、「OK」をクリックします。

今回は、ユーザー(k8s-infra-user)を指定していますが、一般的にはグループを指定するはずです。

ロールでは、「編集可能」(edit) または、「表示可能」(view)が選択できます。

tkc-access-05.png

 

権限が追加されました。

tkc-access-06.png

 

1-2: kubectl での接続。

kubectl vsphere login でログインすると、kubeconfig のファイルが生成されます。

デフォルトでは、$HOME/.kube/config というファイル名で作成されますが、

環境変数 KUBECONFIG を設定しておくと、そのパスに生成されます。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkc

 

kubectl vsphere login では、次のようなオプションを指定します。

  • --server: Tanzu Kubernetes Cluster の制御プレーンではなく、
    スーパーバイザー クラスタの、制御プレーンが持つ IP アドレス(この環境では 192.168.70.97)を指定します。
  • --tanzu-kubernetes-cluster-namespace: TKC を作成したスーパーバイザー名前空間
  • --tanzu-kubernetes-cluster-name: TKC の名前

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41

 

Username: k8s-infra-user@go-lab.jp

Password: ★パスワードを入力。

Logged in successfully.

 

You have access to the following contexts:

   192.168.70.97

   lab-ns-03

   tkg-cluster-41

 

If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.

 

To change context, use `kubectl config use-context <workload name>`

$

 

TKC「tkg-cluster-41」と、TKC のスーパーバイザー名前空間「lab-ns-03」と同名のコンテキストが作成されます。

ここでも、TKC  の制御プレーン アドレス「192.168.70.99」がわかります。

$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                     NAMESPACE

*         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-infra-user@go-lab.jp

 

TKC のノードが表示できました。

$ kubectl --context tkg-cluster-41 get nodes

NAME                                            STATUS   ROLES    AGE    VERSION

tkg-cluster-41-control-plane-vcdpg              Ready    master   153m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   131m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   127m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   131m   v1.17.8+vmware.1

 

ちなみに権限を追加していなかったり、ロールが「表示可能」の場合はエラーになります。

$ kubectl --context tkg-cluster-41 get nodes

Error from server (Forbidden): nodes is forbidden: User "sso:k8s-infra-user@go-lab.jp" cannot list resource "nodes" in API group "" at the cluster scope

 

なお、TKC で Deployment リソースなどで Pod を作成するには、PodSecurityPolicy の設定が必要になったりします。

(これは、この後の方法でも同様です)

vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

 

方法2: Kubernetes の管理ユーザ(kubernetes-admin)として接続する。

この方法では、TKC を作成してあるスーパーバイザー名前空間「lab-ns-03」に自動作成されている Secret リソースから、kubeconfig の情報を取得します。

これは、あらかじめ kubectl vsphere login でスーパーバイザー クラスタか TKC に接続したうえで取得することになります。

 

kubernetes-admin の kubeconfig での接続は、直接 TKC の管理プレーン宛を指定します。

tkc-access-case-02.PNG

 

2-1: kubernetes-admin ユーザーの kubeconfig の取得。

Secret リソースは、「<Tanzu Kubernetes Cluster の名前>-kubeconfig」となっており、

この環境では「tkg-cluster-41-kubeconfig」です。

$ kubectl --context lab-ns-03 get secrets tkg-cluster-41-kubeconfig

NAME                        TYPE     DATA   AGE

tkg-cluster-41-kubeconfig   Opaque   1      167m

 

JSON パスでの「{.data.value}」に、base64 エンコーディングされた kubeconfig が格納されています。

この内容を、「base64 -d」コマンドでデコードして、ファイルに保存します。

$ kubectl --context lab-ns-03 get secret tkg-cluster-41-kubeconfig -o jsonpath='{.data.value}' | base64 -d > ./kubeconfig_tkg-cluster-41

 

2-2: 生成した kubeconfig での kubectl 接続。

保存した kubeconfig で、管理ユーザーのコンテキストで TKC に接続できます。

これは、vCenter Single Sign-On の認証とは関係なく接続できるものです。

$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 config current-context

kubernetes-admin@tkg-cluster-41

$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 get nodes

NAME                                            STATUS   ROLES    AGE    VERSION

tkg-cluster-41-control-plane-vcdpg              Ready    master   155m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   133m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   129m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   133m   v1.17.8+vmware.1

 

方法3: Kubernetes の ServiceAccount を作成して接続する。

方法1か、方法2の、いずれかで TKC に接続したうえで、TKC の名前空間に ServiceAccount を作成して接続します。

ServiceAccount での TKC への接続も、スーパーバイザー制御プレーンではなく、TKC 制御プレーン宛となります。

tkc-access-case-03.PNG

 

3-1: ServiceAccount の作成。

ここからは、ちょうど直前の 方法2 で作成した kubeconfig を利用します。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41

$ kubectl config current-context

kubernetes-admin@tkg-cluster-41

 

この時点では TKC の「default」名前空間を使用していますが、

あらたに「tkg-ns-01」という名前空間を作成して、そこに ServiceAccount で接続できるようにします。

$ kubectl create namespace tkg-ns-01

namespace/tkg-ns-01 created

 

この時点 tkg-ns-01 名前空間に存在するのは、ServiceAccount(sa) は default のみです。

$ kubectl -n tkg-ns-01 get sa

NAME      SECRETS   AGE

default   1         43s

 

ServiceAccount「sa-01」を作成します。

$ kubectl -n tkg-ns-01 create sa sa-01

serviceaccount/sa-01 created

$ kubectl -n tkg-ns-01 get sa

NAME      SECRETS   AGE

default   1         47s

sa-01     1         12s

 

この ServiceAccount のトークンが格納されている、Secret リソースの名前を確認します。

$ SA_SECRET_NAME=$(kubectl -n tkg-ns-01 get sa sa-01 -o jsonpath='{.secrets[0].name}')

$ echo $SA_SECRET_NAME

sa-01-token-zc74c

 

Secret リソースから、トークンを取得します。

$ SA_TOKEN=$(kubectl -n tkg-ns-01 get secrets $SA_SECRET_NAME -o jsonpath='{.data.token}' | base64 -d)

 

確認したトークンをもとに、Credential、コンテキストを作成します。

$ kubectl config set-credentials sa-01 --token=$SA_TOKEN

User "sa-01" set.

$ kubectl config set-context ctx-sa-01 --user=sa-01 --cluster=tkg-cluster-41 --namespace=tkg-ns-01

Context "ctx-sa-01" created.

 

コンテキストを kubeconfig ファイルとして保存しておきます。

$ kubectl config view --minify --context=ctx-sa-01 --raw > ./kubeconfig_ctx-sa-01

$ kubectl config delete-context ctx-sa-01

 

ServiceAccount で接続する kubeconifg が生成されました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 config get-contexts

CURRENT   NAME        CLUSTER          AUTHINFO   NAMESPACE

*         ctx-sa-01   tkg-cluster-41   sa-01      tkg-ns-01

 

3-2: ServiceAccount の権限設定。

作成した ServiceAccount「sa-01」が Kubernetes のリソースを操作できるように、

ClusterRole「edit」を割り当てる RoleBinding を作成しておきます。

 

role-binding-edit.yml

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: rb-edit-sa-01

roleRef:

  kind: ClusterRole

  name: edit

  apiGroup: rbac.authorization.k8s.io

subjects:

- kind: ServiceAccount

  name: sa-01

 

RoleBinding を、TKC の tkg-ns-01 名前空間に作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-edit.yml

rolebinding.rbac.authorization.k8s.io/rb-edit-sa-01 created

 

TKC で Pod を起動できるように、PodSecurityPolicy を割り当てる RoleBinding も作成しておきます。

こちらは、すべての ServiceAccount を指定しています。

 

role-binding-psp.yml

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: rb-vmware-system-privileged

roleRef:

  kind: ClusterRole

  name: psp:vmware-system-privileged

  apiGroup: rbac.authorization.k8s.io

subjects:

- kind: Group

  name: system:serviceaccounts

  apiGroup: rbac.authorization.k8s.io

 

TKC の名前空間に RoleBinding を作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-psp.yml

rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created

 

3-3: 生成した kubeconifg での kubectl 接続。

生成した kubeconfig で、Pod の起動ができました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 get pods

NAME     READY   STATUS              RESTARTS   AGE

pod-01   1/1     Running             0          44s

 

Pod は削除しておきます。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01.txt delete pod pod-01

pod "pod-01" deleted

 

方法4: TKC 側で vCenter Single Sign-On ユーザーの権限を割り当てる。

あらかじめ、方法1、または方法2の、いずれかの方法で TKC に接続しておきます。

そして方法1 とは異なり、TKC で作成した名前空間に vCenter Single Sigh-On ユーザーの権限を割り当てます。

そのあとの TKC への接続はスーパーバイザー制御プレーン宛となります。

tkc-access-case-04a.png

 

方法4-1: TKC の名前空間への権限の追加。

ここでは、方法2 で生成した kubeconfig を利用して、TKC を操作します。

(方法1 の接続でも同様に操作できます)

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41

$ kubectl config current-context

kubernetes-admin@tkg-cluster-41

 

TKC の名前空間「tkg-ns-02」を追加作成します。

あわせて、PSP の RoleBinding(YAML は方法3のものと同様)も作成しておきます。

$ kubectl create namespace tkg-ns-02

namespace/tkg-ns-02 created

$ kubectl -n tkg-ns-02 apply -f role-binding-psp.yml

rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created

 

RoleBinding の YAML を用意します。

リソースを操作できるように、ClusterRole「edit」を割り当てます。

subjects では vCenter Single Sign-On ユーザー(sso:k8s-dev-user@go-lab.jp)を指定しています。

ちなみに、グループを指定する場合は、「kind: User」を「kind: Group」にします。

 

role-binding-vcsso.yml

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: rb-edit-k8s-dev-user

roleRef:

  kind: ClusterRole

  name: edit

  apiGroup: rbac.authorization.k8s.io

subjects:

- kind: User

  name: sso:k8s-dev-user@go-lab.jp #sso:<username>@<domain>

  apiGroup: rbac.authorization.k8s.io

 

作成した TKC の名前空間「tkg-ns-02」に、RoleBinding を作成します。

$ kubectl -n tkg-ns-02 apply -f role-binding-vcsso.yml

rolebinding.rbac.authorization.k8s.io/rb-edit-k8s-dev-user created

 

方法4-2: kubectl での接続。

既存の kubeconfig を上書きしないように、環境変数 KUBECONFIG に、新しい kubeconfig ファイルのパスを指定します。

この時点では「kubeconfig_k8s-dev-user」ファイルは存在しません。

$ export KUBECONFIG=$(pwd)/kubeconfig_k8s-dev-user

 

kubectl vsphere login で、スーパーバイザー制御プレーンと TKC に接続します。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41

 

Username: k8s-dev-user@go-lab.jp

Password: ★パスワードを入力。

Logged in successfully.

 

You have access to the following contexts:

   192.168.70.97

   tkg-cluster-41

 

If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.

 

To change context, use `kubectl config use-context <workload name>`

$

 

コンテキストが生成されました。

$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE

*         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-dev-user@go-lab.jp

 

コンテキストを TKC の「tkg-cluster-41」に切り替えて、

デフォルトの名前空間として「tkg-ns-02」を設定します。

$ kubectl config use-context tkg-cluster-41

Switched to context "tkg-cluster-41".

$ kubectl config set-context --current --namespace=tkg-ns-02

Context "tkg-cluster-41" modified.

$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE

*         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-dev-user@go-lab.jp   tkg-ns-02

 

Pod が起動できました。

$ kubectl run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ kubectl get pods -n tkg-ns-02

NAME     READY   STATUS    RESTARTS   AGE

pod-01   1/1     Running   0          10s

 

スーパーバイザー名前空間「lab-ns-03」では「k8s-dev-user」ユーザーへの権限は追加していませんが、

vCenter Single Sigh-On ユーザーでリソース作成ができました。

vSphere Client で確認すると、方法1 で使用した「k8s-infra-user」ユーザーのみが追加されています。

tkc-access-09.png

 

vCenter 同梱ではない kubectl の接続。

ちなみに、ここまでの方法に関わらず、kubeconfig が生成できていれば

一般的な Kubernetes 操作ツールでも TKC に(スーパーバイザー クラスタにも)接続することができます。

 

Kubernetes のドキュメントでおなじみの URL から kubectl をダウンロードします。

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.8/bin/linux/amd64/kubectl

$ chmod +x ./kubectl

 

vCenter 同梱の kubectl と、あらたにダウンロードした kubectl(./kubectl でカレント ディレクトリのものを実行)です。

$ kubectl version --short

Client Version: v1.17.4-2+a00aae1e6a4a69

Server Version: v1.17.8+vmware.1

$ ./kubectl version --short

Client Version: v1.17.8

Server Version: v1.17.8+vmware.1

 

どちらの kubectl でも、普通に TKC を操作できます。

$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user get pods

NAME     READY   STATUS    RESTARTS   AGE

pod-01   1/1     Running   0          15s

 

Tanzu Kubernetes Cluster は、kubectl + vSphere プラグインによる vCenter Single Sign-On の認証だけでなく、

一般的な kubernetes と同様なクラスターへの接続ができます。

いくつか接続方法を試しましたが、もっとよい方法もあるかもしれません。

 

以上、いろいろと Tanzu Kubernetes Cluster への接続を試してみる話でした。

1 2 Previous Next

Actions

Looking for a blog?

Can't find a specific blog? Try using the Blog page to browse and search blogs.